[whatwg] Delivery reports about your e-mail
Re: [whatwg] Selectors within style scoped
On 2011-06-17 09:36, Roland Steiner wrote: On Fri, Jun 17, 2011 at 4:10 PM, Roland Steinerrolandstei...@google.comwrote: http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class says: The :scopehttp://dev.w3.org/2006/webapi/selectors-api2/#scope pseudo-class *must* match any element that is a contextual reference elementhttp://dev.w3.org/2006/webapi/selectors-api2/#contextual-reference-element. so :scope is ambiguous if you have several scoping elements as ancestors. :scope in a nested sheet, meant to limit the rule to the nested scoping element, may instead match against an enclosing scoping element. Again, see the example I mailed earlier. Actually, re-reading that section I think I misunderstood the meaning. If only the direct parent of astyle scoped is considered a contextual reference element for rules in _that_ style-sheet (rather than an element being a contextual reference element for _some_ scoped stylesheet), there is no ambiguity. That is correct. However, note that the definition of :scope itself does not define which elements are the contextual reference elements (except where it defaults to the document root element) and it can it theory support more than one [1]. But it is up to the specification defining a particular context to define what the contextual reference elements are, and HTML5 needs to define that the contextual reference element for a given scoped stylesheet is its parent element. [1] In fact, the refNodes parameter of the querySelector* methods explicitly allows there to be more than one in that context. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Selectors within style scoped
On 2011-06-15 08:40, Roland Steiner wrote:
According to the HMTL5 spec, selectors are not limited to children of the
scoping element (the parent element ofstyle scoped). For example:
div class=foo
div
style scoped
.foo p { display: none }
/style
pTo be or not to be, that is the question./p
/div
div
In above snippet, the selector in the scoped stylesheet would match, causing
thep element to be hidden...
The disadvantages:
1.) a scoped style may unexpectedly apply, because an arbitrary ancestor of
the scoping element happens to partially match the scoped selector
This is the purpose of the :scope pseudo-class that is defined to match
the contextual reference elemnt, which for scoped stylesheets, will be
the parent of the style element.
So you could rewrite the style above to be:
:scope .foo p { display: none }
Then .foo will only match elements within the div.
http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Submitting datetime values should more clearly specify required timezone syntax
On 2011-06-16 00:00, Ian Hickson wrote: On Wed, 30 Mar 2011, Lachlan Hunt wrote: The spec states for submission of datetime controls that the value must be expressed in the UTC time-zone. It's not clear whether this requires the formatted string to state the timezone as an uppercase Z or +00:00, or whether either is acceptable. Most of the examples illustrate the use of the Z I couldn't find any examples of the output of this; did I miss some? I was referring to examples of datetimes in general, such as where the spec defines date and time format, not specifically to example form submission output. Opera has always submitted the value with a Z and not +00:00, and we would prefer not to change this for backwards compatibility and ease of parsing on the server side. The spec should define in the value sanitization algorithm for the date and time time state, to express the UTC time-zone using a Z. Done. Thanks. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Selectors within style scoped
On 2011-06-16 19:40, Tab Atkins Jr. wrote: I was convinced that @scoped worked exactly like this until this thread. Apparently my previous reading of the spec was insufficiently deep to spot the scoping/filtering difference. FWIW, I also think that querySelector got this wrong. It should have scoped by default, and then possibly also offered an option to filter based on an element. I analysed this issue in depth when I wrote Selectors API, and even revisited it when I tried to introduce the queryScopedSelector methods. But it doesn't work without altering the syntax of selectors, like JQuery does, such as allowing selectors to begin with combinators and creates other unintended side affects. I don't have time to write up a full explanation now, but most of the rationale is somewhere in the public-webapps archives. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Time Parsing
On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-19 19:33, Ian Hickson wrote: On Tue, 12 Apr 2011, Lachlan Hunt wrote: We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. [...] We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. I haven't updated the spec yet, but it strikes me that maybe what we should do instead is have a whitelist of protocols we definitely want to allow (e.g. mailto:), and define a common prefix for protocols that are used with this feature, in a similar way to how with XHR we've added Sec-* as a list of headers _not_ to support. Other protocols we should probably also whitelist: irc, sms, smsto, tel. I'm also curious how we could handle ISBN URNs, like: urn:isbn:0-395-36341-1 That would be useful to have a web service that could look up the ISBN and direct users to information about the book, or to an online store. As currently specified, services have to register a handler for urn, even if they only handle ISBN URNs. The other alternative would be to mint a new web+isbn scheme, which seems suboptimal. So e.g. we could whitelist any protocol starting with web+ and then register that as a common extension point for people inventing protocols for use with this feature, so that people writing OS-native apps would know that if they used a protocol with that prefix it's something that any web site could try to take over. That seems reasonable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-19 20:29, Tab Atkins Jr. wrote: On Tue, Apr 19, 2011 at 11:11 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: I'm also curious how we could handle ISBN URNs, like: urn:isbn:0-395-36341-1 That would be useful to have a web service that could look up the ISBN and direct users to information about the book, or to an online store. As currently specified, services have to register a handler for urn, even if they only handle ISBN URNs. The other alternative would be to mint a new web+isbn scheme, which seems suboptimal. Presumably we can specifically whitelist urn:isbn as a scheme to support (and adjust the algorithm sufficiently to make this do what's intended)? Are there other nested urn: schemes that we could expose? If so, we could just make the whole class of urn:* protocols available. http://en.wikipedia.org/wiki/Uniform_Resource_Name#Examples http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Blacklist for regsiterProtocolHandler()
Hi, We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. Our list currently includes: * http: * https: * ftp: * file: * about: * data: Email specific schemes: * cid: * mid: Scripting schemes: * javascript: * vbscript: Ancient Netscape scripting schemes. some were apparently aliases for javascript: * mocha: * livescript: * livewire: * tcl: Also, implementers need to be take care with vendor specific schemes: * chrome: (Mozilla, Chrome) * view-source: (Mozilla, Chrome) * res: (IE) * resource: (Mozilla) * opera: (Opera) * attachment: (Opera) (This list is probably incomplete) We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-12 16:18, Lachlan Hunt wrote: Hi, We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. Our list currently includes: * http: * https: * ftp: * file: Also, blob: Ancient Netscape scripting schemes. some were apparently aliases for javascript: * mocha: * livescript: * livewire: * tcl: Correction: tcl wasn't Netscape, it was some other minor browser. Not sure which one. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Styling details
On 2011-04-08 23:20, Jukka K. Korpela wrote:
Tab Atkins Jr. wrote:
On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Tab Atkins Jr. wrote:
details is definitely something we want to make fully
author-stylable.
I don’t. Who’s this ”we” you are talking about, and why do they want
to make details author-stylable even before a single browser has
_any_ support to the element, at the functional level?
We being, I suspect, the browser community.
Thank you for the clarification. I would prefer seeing _one_ decent
implementatiom of details before considering any fine tuning.
We, Opera, have an internal implementation. Chrome are also working on
their implementation of it in WebKit. We would like our implementations
to be compatible as far as author styling is concerned, and so it is
very useful to discuss the fine-tuning of CSS styling before we ship.
If we did not do this, then you and every other author would most
certainly complain when Opera and Chrome ship incompatible
implementations that require vastly different approaches to styling.
If that's overreaching,
then I'm content to say that *I* want it to be fully author-stylable,
The primary question, as I see it, is to get decent implementations in
the first place. I don’t see crowds of authors yelling for
author-stylability.
Authors have been yelling for author-styling in relation to many other
elements in the past. In particular, fieldset and legend are
paticularly troublesome because their default appearance and the effect
of applying various CSS properties is literally impossible to express
using CSS or XBL right now, and differnet implementations have slightly
different behaviour in some cases. This severely limits what authors
can do with those elements. Authors have also been yelling for more
ability to style form controls.
As far as details elements are concerned, our developer relations team
at Opera have been discussing these new HTML features with the web
developer community for a long time, and styling is absolutely among the
the top concerns that they pass on to us.
Does it? Why do you imply the visual concept of a ”disclosure
triangle”, and how does that relate to the behavior proposed for
”::marker” in some draft?
I don't understand the question.
Why does details need to have any ”disclosure triangle”?
The default appearance needs a disclosure widget of some kind, either a
triangle or plus symbol or whatever. However, since these default
appearances will not suit all needs, it is essential that authors be
able to change this freely in their pages, which is why we need to
discuss the finer details of how the default styling is defined. This
includes defining suitable 'list-style-type' values for the open and
closed states ('disclosure-open' and 'disclosure-closed'), which authors
may override.
However, the default visual behavior of details is suggested in
the HTML spec.
... And I would not take it as more than a suggestion in a work in
progress, which is what it really is.
Yes, it is a suggestion. But as we are now implementing it, we are
trying to ensure that the spec can be made clearer and more accurate.
I know that many CSS property names are misleading. But
list-style-type, as defined in published CSS recommendations, isn’t
bound to any ”::marker”.
It certainly is, in the Lists spec.
Please cite the recommendation by its official name and/or URL.
http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On 2011-04-08 11:23, James Graham wrote:
FWIW I don't think we need cross-browser agreement here. In particular I
think browsers should be free to implement details using a
platform-native disclose widget if they like. These are not all alike
e.g. OSX uses something like ▸, Windows something like [+] (I think?)
and Gnome (at least with the skin I have) something like ▷.
Regardless of whether or not we agree on a common glyph to use for this,
we should at least agree on the applicable CSS styles used to achieve
the rendering, which is essential so that authors have an easier time
override them with their own styles.
If we use 'list-style-type', it seems reasonable to at least agree on a
common list-style-type value. Existing list-style-type values in CSS do
define applicable Unicode characters [1], which is why I suggested them.
One option is to define that the list-style-type 'disclosure-*' as magic
values that mean to render a UA specific/platform dependent widget. But
that differs from all other list-style-type values and doesn't seem
quite right.
CSS3-UI, however, uses the 'appearance' property to render native
looking controls.
In theory, native widgets could be achieved instead by using a new
'appearance' value like:
summary::marker { appearance: -x-disclosure; }
(Assuming the 'appearance' value handles the open/close states
automatically, and any animations that would be expected of native controls)
But that would make it slightly harder for authors to restyle as we
don't yet implement ::marker, and won't implement it until we have time
to do it properly for list-items in general (we don't want to a quick
hack just for summary).
Authors would have to do this:
summary::marker { appearance: normal; }
summary { list-style-image: url(...); }
[open] summary { list-style-image: url(...); }
[1] http://dev.w3.org/csswg/css3-lists/#glyph-counters
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On 2011-04-08 18:19, Tab Atkins Jr. wrote: This isn't quite true. The three CSS2.1 bullet styles, for example, are all different on at least one browser. I've specced them specially in Lists such that there is a recommended glyph but browsers are free to use any graphic that's roughly similar. I could easily take a similar approach for the disclosure triangle. OK, that might be acceptable. Though, there are likely to be platform dependent rendering expectations, like hover effects or animations like rotating the triangle when changing from 'disclosure-closed' to 'disclosure-open'. If the spec can make that permissible, then I think that will be acceptable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Styling details
On 2011-04-06 02:56, Lachlan Hunt wrote:
To render this, the following CSS should be applied by the UA stylesheet.
detailssummary:first-of-type {
display: list-item;
margin-left: 1em; /* LTR-specific: use 'margin-right' for rtl elements */
list-style-type: -o-disclosure-closed;
}
details[open]summary:first-of-type {
list-style-type: -o-disclosure-open;
}
There are a few other issues that we have identified.
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks
mode, and based on the font-size in standards mode. This is a quirk
implemented by Firefox, IE and Opera for display: list-item; though
WebKit doesn't seem to. We are not sure if this quirk is still required
for web compatibility.
2. If the author attempts to shoot their own foot off by using:
summary { display: none; }
This leaves an empty details box of zero height in the closed state
with no way to open it, and the renders the content without a summary or
disclosure widget in the details open state.
We think this is acceptable, and that we should not introduce the magic
that exists in Chrome's experimental implementation, where they render
the default summary that says Details.
3. We'd like to get some feedback from web developers, and agreement
from other browser vendors, about exactly which glyphs are most
appropriate to use for these disclosure states. We considered two
alternatives, but we think these three glyphs are the most appropriate.
U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE
U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE
U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE
The other alternative we considered was a larger set of triangle glyphs
that were too big for this purpose.
We created a custom SVG font with these glyphs, and I've put up a page
illustrating how each of these look.
http://lachy.id.au/dev/2011/triangle.html
(Use Opera to see the SVG font)
Copies of these glyphs (rendered with list-style-image instead) are now
being used in the simulation I created before.
http://lachy.id.au/dev/2011/details.html
(Check the directory listing there to get all the image files if you
want them.)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On 2011-04-06 03:36, Tab Atkins Jr. wrote:
I like the idea of using display:list-item for thesummary. It has
some unfortunate weaknesses due to the way that display:list-item is
defined; in particular, you can't get an inline summary without losing
the disclosure marker, since there's no way to make an inline
list-item right now.
If authors want to do that now, it's not such a big deal for them to
provide their own disclosure icon as a background image in the padding
area, or to use this in their own styles:
[open]summary::before { content: url(open.png); }
summary::before { content: url(closed.png); }.
I expect this to be fixed on the CSS side in due
time, with the 'display' property split into some subproperties such
that ::marker generation is independent of the list item being inline
or block.
Yes, that will be useful.
I also like the display:transparent idea for handling the wrapper
around the rest of the contents.
:-)
Swapping out bindings (the second solution) feels hacky and bad.
Using a details-specific pseudo-element (the third solution)
doesn't actually solve the problem - it's still a box surrounding the
extra content, so it would suffer from the same problem that was
previous cited, where setting display:table-cell on an element in the
contents wouldn't work as intended. Its only good side is that you
can style the pseudoelement directly, which would make *some*
use-cases salvageable.
Agreed, that's why I said it only provides a workaround, and we are not
taking that approach internally.
Our implementation will be black-box-equivalent to the first two
alternatives, minus the XBL bindings, and our UA stylesheet will be
exactly as I described in the proposed solution.
So either of those approaches should be acceptable, though I do prefer
the more elegant display:transparent; approach.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On 2011-04-06 22:45, Tab Atkins Jr. wrote: Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. That's true, but if the controls are readonly, then the user can't change the value and so why does that matter? Could you clarify the use case for having a readonly checkbox value submitted? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Styling details
in the binding as follows:
binding id=details-closed
template allow-selectors-through=true
content
includes=:bound-elementsummary:first-of-typesummaryDetails/summary/content
span id=content pseudo=-o-contentcontent/content/span
/template
/binding
UA styles could then be used to hide and show the content as needed
details::-o-content {
display: none;
}
details[open]::-o-content {
display: block;
}
Limitations:
This requires the creation of a new element-specific pseudo-element
specifically for use with details, which is not as nice as a more
general purpose solution that can be applied to other situations. It
also doesn't really address the problem directly, but instead merely
provides authors with a workaround.
== Open Issues ==
1. The summary should be focusable for keyboard navigation and
activation. This can't use tabindex in the binding, but rather should
be handled natively by the implementation like links or form controls.
For consistency, it needs to be possible to override if the author sets
summary tabindex=-1.
2. Should the default Details string change based on the user's
browser language, the page's language, or not change at all?
3. As stated earlier, we would like feedback regarding padding/margin issue.
[1] http://dev.w3.org/2006/xbl2/#simple-shadow-example
[2] http://whatwg.org/C#the-details-element-0
[3] http://images.whatwg.org/sample-details-2.png
[4] http://lachy.id.au/dev/2011/details.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] details for long description of image/ video etc
On 2011-04-02 10:30, John Foliot wrote:
Interesting question. Referring to the spec, I think that you may
have in fact uncovered a bug in the text. The spec states:
The user agent should allow the user to request that the details be
shown or hidden.
The problem (or potential problem) here is that the behaviour is
defined in visual terms
The Terminology section of the spec clearly states:
For simplicity, terms such as shown, displayed, and visible might
sometimes be used when referring to the way a document is rendered
to the user. These terms are not meant to imply a visual medium;
they must be considered to apply to other media in equivalent ways.
If details default Boolean setting of 'hidden' results in the
equivalent of CSS's {display:none;} (where the content is taken
completely out of the page flow, both visually and in the DOM tree) then
this would likely be a possible alternative to @longdesc
Yes, it should be implemented equivalent to display:none.
If however it is simply hidden visually, but is forced upon
non-visual users (to listen to the description), then this 'forcing'
to hear the content would be considered unacceptable.
No, the implementation should not do that.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[whatwg] Invoking getUserMedia() with Unknown Options
Hi, When getUserMedia() is invoked with unknown options, the spec currently implicitly requires a PERMISSION_DENIED error to be thrown. e.g. navigator.getUserMedia(foo); In this case, the option for foo is unknown. Presumably, this would fall under platform limitations, and would thus jump from step 11 to the failure case, and throw a permission denied error. We are wondering if this is the most ideal error to throw in this case, as opposed to introducing a more logical NOT_SUPPORTED error, and if it might be useful to authors to distinguish these cases? We assume, however, that if the author requests audio,foo, and the user grants access to audio, then the success callback would be invoked, despite the unknown option for foo. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Submitting datetime values should more clearly specify required timezone syntax
Hi, The spec states for submission of datetime controls that the value must be expressed in the UTC time-zone. It's not clear whether this requires the formatted string to state the timezone as an uppercase Z or +00:00, or whether either is acceptable. Most of the examples illustrate the use of the Z, but elsewhere in the spec, following the definition of the valid global date and time string, it recommends against using the Z. The *best representation of the global date and time string* datetime is the valid global date and time string representing datetime, with the valid time string component being given in its shortest possible form, with the last character of the string not being a U+005A LATIN CAPITAL LETTER Z character (Z), even if the time zone is UTC, and with a U+002B PLUS SIGN character (+) representing the sign of the time-zone offset when the time zone is UTC. http://whatwg.org/C#best-representation-of-the-global-date-and-time-string (Note that the spec defines this best representation... term, but never actually uses it anywhere. It's not clear what the purpose of that definition is.) Opera has always submitted the value with a Z and not +00:00, and we would prefer not to change this for backwards compatibility and ease of parsing on the server side. The spec should define in the value sanitization algorithm for the date and time time state, to express the UTC time-zone using a Z. http://whatwg.org/C#date-and-time-state -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Time Parsing
Hi, The algorithm to parse a time component contains a bug. When parsing the seconds, the spec states: Collect a sequence of characters that are either characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL STOP characters. If the collected sequence has more than one U+002E FULL STOP characters, or if the last character in the sequence is a U+002E FULL STOP character, then fail. Otherwise, let the collected string be second instead of its previous value. This is incorrect because it allows the second component to contain more than 2 digits before the decimal point. i.e. 00:00:012.345 would parsed without error. The algorithm should instead state to look for 2 digits representing the seconds, then check if there's a decimal point, and then check for the fractional part of the second. This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. e.g. 00:00:00. Technically, that would be 999,900µs, but it needs to be rounded down to 999ms, not rounded up to 1s. http://whatwg.org/C#parse-a-time-component -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Peer-to-peer communication, video conferencing, device, and related topics
On 2011-03-18 15:02, Lachlan Hunt wrote:
On 2011-03-18 05:45, Ian Hickson wrote:
On Mon, 24 Jan 2011, Anne van Kesteren wrote:
...
audio.src = blob
(The src content attribute would then be something like
about:objecturl.)
Could you elaborate on this plan?
... we avoid the unnecessary overhead of creating a magic URL, and
instead just assign the object directly to the src property...
i.e.
video/video
script
var v = document.querySelector(video);
navigator.getUserMedia(video, function(stream) {
v.src = stream;
v.play();
});
/script
The getter for v.src then returns about:streamurl.
We've just released a preview build of Opera Mobile on Android that
supports this functionality as described above.
http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[whatwg] Video and Audio Tracks API
Hi,
This is regarding the recently added audioTracks and videoTracks APIs
to the HTMLMediaElement.
The design of these APIs seems to be done a little strangely, in that
dealing with each track is done by passing an index to each method on
the TrackList interfaces, rather than treating the audioTracks and
videoTracks as collections of individual audio/video track objects.
This design is inconsistent with the design of the TextTrack interface,
and seems sub-optimal.
The use of ExclusiveTrackList for videoTracks also seems rather
limiting. What about cases where the second video track is a
sign-language track, or some other video overlay. This is a use case
that you seem to be trying to address with the mediaGroup feature, even
though the example given actually includes all tracks in the same file.
The example from the spec is:
video src=movie.vid#track=Videoamp;track=English autoplay controls
mediagroup=movie/video
video src=movie.vid#track=sign autoplay mediagroup=movie/video
Normally, sign language tracks I've seen broadcast on TV programs
display the sign language interpreter in a small box in the bottom corner.
Other use cases include PiP features, such as director commentary or
storyboards as available on some Blu-ray and DVDs [1]. So in cases
where both tracks are included in the same file, having the ability to
selectively enable multiple video tracks would seems easier to do than
synchronising separate video files.
There are also the use cases for controlling the volume of individual
tracks that are not addressed by the current spec design.
I believe the design would work better like this:
---
interface HTMLMediaElement : HTMLElement {
...
readonly attribute AudioTrack[] audioTracks;
readonly attribute VideoTrack[] videoTracks;
}
interface MediaTrack {
readonly attribute DOMString label;
readonly attribute DOMString language;
attribute boolean enabled;
}
Interface AudioTrack : MediaTrack {
attribute double volume;
attribute boolean muted;
// Other potential future APIs include bass, treble, channels, etc.
}
Interface VideoTrack : MediaTrack {
// ...
}
---
This proposal replaces TrackList.getName(index) with
MediaTrack[index].label, and .getLanguage(index) with .language, which
is more consistent with the design of the TextTrack interface. The
isEnabled(), and enable() and disable() functions have also been
replaced with a single mutable boolean .enabled property.
[1] http://en.wikipedia.org/wiki/Picture-in-picture
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Peer-to-peer communication, video conferencing, device, and related topics
On 2011-03-18 05:45, Ian Hickson wrote:
On Thu, 16 Sep 2010, Jonathan Dixon wrote:
Further, it could be useful to provide a way to query the video source
as to whether the camera is oriented relative to the screen (if the
underlying system knows; consider a phone device with both a main camera
and self-view camera). This is needed to drive the decision on whether
to do this horizontal flip or not. In fact, such an application may want
to somehow indicate a preference for the self-view camera when multiple
cameras are present in the selection list. c.f. a movie-making app which
would prefer the outward facing camera.
Interesting.
In getUserMedia() the input is extensible; we could definitely add
prefer-user-view or prefer-environment-view flags to the method (with
better names, hopefully, but consider that 'rear' and 'front' are
misleading terms -- the front camera on a DSLR faces outward from the
user, the front camera on a mobile phone faces toward the user). The user
still has to OK the use of the device, though, so maybe it should just be
left up to the user to pick the camera? They'll need to be able to switch
it on the fly, too, which again argues to make this a UA feature.
We could just add flags to the options string like this:
video;view=user, audio or video;view=environment, audio
It's worth pointing out that The HTML Media Capture draft from the DAP
WG uses the terms camera and camcorder for this purpose, but I find
these terms to be very ambiguous and inappropriate, and so we should not
use them here.
http://dev.w3.org/2009/dap/camera/
Similarly for exposing the kind of stream: we could add to GeneratedStream
an attribute that reports this kind of thing. What is the most useful way
of exposing this information?
I'm not entirely clear about what the use cases are for knowing if the
camera is either user-view or environment-view. It seems the more
useful information to know is the orientation of the camera. If the
user switches cameras, that could also be handled by firing orientation
events.
Lachlan Hunt wrote:
There are some use cases for which it would be useful to know the
precise orientation of the camera, such as augmented reality
applications. The camera orientation may be independent of the device's
orientation, and so the existing device orientation API may not be
sufficient.
It seems like the best way to extend this would be to have the Device
Orientation API apply to GeneratedStream objects, either by just having
the events also fire on GeneratedStream objects, or by having the API be
based on a pull model rather than a push model and exposing an object on
GeneratedStream objects as well as Window objects.
This could work. But it would make more sense if there were an object
representing the device itself, as in Rich's proposal, and for the
events to be fired on that object instead of the stream.
On Mon, 24 Jan 2011, Anne van Kesteren wrote:
There is a plan of allowing direct assigning to IDL attributes besides
creating URLs.
I.e. being able to do:
audio.src = blob
(The src content attribute would then be something like about:objecturl.)
I am not sure if that API should work differently from creating URLs and
assigning those, but we could consider it.
Could you elaborate on this plan?
This is basically what Philip and I were discussing in the other thread
yesterday, where we avoid the unnecessary overhead of creating a magic
URL, and instead just assign the object directly to the src property.
This lets the implementation handle all the magic transparently in the
background, without bothering to expose a URLs string to the author.
This is what we had implemented in our experimental implementation of
the device element, and now getUserMedia.
i.e.
video/video
script
var v = document.querySelector(video);
navigator.getUserMedia(video, function(stream) {
v.src = stream;
v.play();
});
/script
The getter for v.src then returns about:streamurl.
My understanding is that we don't really want to have to implement the
create/revokeObjectURL() methods for this.
On Wed, 16 Feb 2011, Anne van Kesteren wrote:
This is just a thought. Instead of acquiring a Stream object
asynchronously there always is one available showing transparent black
or some such. E.g. navigator.cameraStream. It also inherits from
EventTarget. Then on the Stream object you have methods to request
camera access which triggers some asynchronous UI. Once granted an
appropriately named event is dispatched on Stream indicating you now
have access to an actual stream. When the user decides it is enough and
turns of the camera (or something else happens) some other appropriately
named event is dispatched on Stream again turning it transparent black
again.
This is a very interesting idea.
This suggests that there would be a separate property available for the
microphone, and any other input device. This differs from the existing
spec, which allowed a single
Re: [whatwg] Peer-to-peer communication, video conferencing, device, and related topics
On 2011-03-18 15:14, Olli Pettay wrote: On 03/18/2011 04:02 PM, Lachlan Hunt wrote: This is basically what Philip and I were discussing in the other thread yesterday, where we avoid the unnecessary overhead of creating a magic URL, and instead just assign the object directly to the src property. This lets the implementation handle all the magic transparently in the background, without bothering to expose a URLs string to the author. And I was arguing that we could avoid creating the probably somewhat heavy stream object if we could just assign the url, or perhaps some DOMURL object to video/audio.src. I don't really understand what you mean by the stream object being heavy. It's necessary anyway because it contains useful methods and events, and so the URL object you are suggesting is an unnecessary indirection that only serves to complicate things. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Stream API Feedback
On 2011-03-17 04:22, Robert O'Callahan wrote: On Thu, Mar 17, 2011 at 4:36 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: I'm not entirely sure I understand your proposal, but are you suggesting that the input streams from the camera/microphone would first go tovideo andaudio elements, allowing the existing HTMLMediaElement API on those elements to be used to control those streams, the output of which can then be encoded and recorded to a file or streamed remotely? Yes. In fact, of all the properties that are on HTMLMediaElement, the only ones that seem to have any real use for streaming media are volume, muted, paused and ended. So I'm not convinced that it's a good idea to try and reuse existing APIs simple for the sake of reusing them, when they aren't really a good fit. As Olli said,video andaudio are designed to support streaming media; streaming over a low-latency network is very much like streaming from a local device. Yes, for playback, that's fine, and that's what we've already implemented in our experimental implementation of the device element. But you seemed to be suggesting that it was sufficient for the purposes of controlling and encoding the video stream, despite the fact that those controls are not at all suited to that. Such control needs to occur before the video element in the chain, not after it. -- --- --- | Camera | -- | GeneratedStream | --+--- | video | -- --- | --- | - - | Codec | -- | Recorded blob | - - | | -- +--- | PeerConnection | -- The stated of the stream, in terms of what gets streamed over P2P or recorded locally, must be controlled at the GeneratedStream and given as input into the codec. This includes things like controlling the input microphone volume, video height and width, etc. In particular, the encoded height and width for streaming may differ significantly from the rendered height and width in the local video preview, so this is not something that can be controlled by the video element itself. In Gecko, we allow seeking within cached segements of streamed video, and we could easily allow that for local devices too --- user-controlled instant replay. We don't buffer any streamed data in our initial device implementation and seeking is not possible. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Stream API Feedback
On 2011-03-17 16:48, Olli Pettay wrote:
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and iframe
for example.
This is getting a bit off topic, but it would be better if they were
also modified so that authors could, instead of doing this:
var file = document.getElementById('file').files[0];
if(file){
blobURLref = window.URL.createObjectURL(file);
myimg.src = blobURLref;
}
(Example from File API spec [1])
Do this:
var file = document.getElementById('file').files[0];
if (file) img.src = file;
The creation of a URL is just an unnecessary step for an issue that can
be handled internally by the browser, and suffers from the problems that
Philip pointed out. Besides, this was all discussed in the WebApps WG
some time ago [2].
[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0169.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Stream API Feedback
On 2011-03-15 21:58, Robert O'Callahan wrote:
Instead of creating new state signalling and control API for streams, what
about the alternative approach of lettingvideo andaudio use sensors as
sources, and a way to connect the output ofvideo andaudio to encoders?
I'm not entirely sure I understand your proposal, but are you suggesting
that the input streams from the camera/microphone would first go to
video and audio elements, allowing the existing HTMLMediaElement API
on those elements to be used to control those streams, the output of
which can then be encoded and recorded to a file or streamed remotely?
I'm not so sure that would be ideal. The state machinary, assuming you
mean the networkState, readyState and their associated constants, are
clearly designed and optimised for obtaining media over a network and do
not map so well to obtaining streams directly from local devices.
Many other properties, such as duration, playbackRate, etc. also do not
have much meaning in the context of streaming media. Some, like
currentTime, only have limited applicability to streams as it can tell
you how long its played for, but must be effectively readonly as seeking
is not possible.
In fact, of all the properties that are on HTMLMediaElement, the only
ones that seem to have any real use for streaming media are volume,
muted, paused and ended. So I'm not convinced that it's a good idea to
try and reuse existing APIs simple for the sake of reusing them, when
they aren't really a good fit.
Then we'd get all the existing state machinery for free. We'd also get
sensor input for audio processing (e.g. Mozilla or Chrome's audio APIs), and
in-page video preview, and usingcanvas to take snapshots, and more...
We can already do in-page video preview with the existing design.
var v = querySelector(video);
navigator.getUserMedia(video, function(stream) {
v.src = stream;
});
From there, taking snapshots with canvas is also possible. We can in
fact already do that with what Opera had implemented for the device
element.
But that's not particularly useful for the audio element. It's rare that
the user would want their microphone input to be echoed back to them via
an audio element. In most cases, when a microphone stream is input into
an audio element, the audio element itself would need to be muted to
prevent unwanted and annoying echo or, worse, feedback loops. That
would only be useful if the audio data were being analysed and output,
for example, to an audio spectrum visualisation (like with Mozilla's
experimental audio data API).
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Thoughts on the media stream bootstrap mechanism
On 2011-03-15 16:24, Rich Tibbett wrote:
We want to replace the success callback with a 'connect' event and the
error callback with an 'error' event. We would also like to introduce
a 'disconnect' event as mentioned in point 3) above.
The IDL is as follows:
[NoInterfaceObject]
interface Device {
const unsigned short WAITING = 0;
const unsigned short CONNECTED = 1;
const unsigned short DISCONNECTED = 2;
const unsigned short ERROR = 3;
readonly attribute unsigned short readyState;
// event handler attributes
attribute Function onconnect;
attribute Function ondisconnect;
attribute Function onerror;
readonly attribute any data;
void disconnect();
}
// Specific Device Classes with independent constructors
[Constructor(in DOMString options)]
interface UserMedia : Device {}
For me, this event model approach seems more natural and fits with
pre-existing design patterns used for other APIs, better than the
callback approach does. But even so, I thought I'd do a side by side
comparison of the code to accomplish a simple tasks.
In both cases, this variable is declared:
var v = document.querySelector(video);
---
/* Callback model: */
var s; // For keeping a reference to the stream available for later use.
navigator.getUserMedia(audio,video, success, error);
function success(stream) {
s = stream; // Store it for later use
v.src = s;
s.onplay = play; // Assume these functions are defined somewhere
s.onpause = pause;
s.onended = ended;
}
function error(e) {
// Permission denied...
}
---
/* Event model: */
var m = new UserMedia(audio,video);
m.onconnect = function(evt) {
v.src = this.data;
this.onplay = play; // Assume these functions are defined somewhere
this.onpause = pause;
this.onended = ended;
}
m.onerror = function(evt) {
// Permission denied
}
---
Based on this simple comparison, it's clear that the neither model
requires significantly more verbose code than the other model, no there
doesn't seem to be any real disadvantage from an authoring perspective.
The event model has the advantage of being able to scale up to handle
more events in the future, such as handling disconnections or the user
switching cameras or microphones. (e.g. The user want switches from
their computer's built in microphone to a USB headset.) For the
callback model to handle that, it would require adding more callback
functions.
One problem with both models is that they don't easily distinguish
between different input devices, which is a problem because both the
proposed Device interface and the Stream/GeneratedStream interfaces can
potentially represent multiple Devices/Streams (this is the case when
audio,video is passed as the type).
This creates a problem when a user, for example, unplugs or revokes
permission for one of the devices or streams but not the other,
triggering either an error or disconnect event, it's not clear how the
script can identify which specific device was disconnected. Both
interfaces also use a single readyState variable to represent the state
of potentially multiple devices/streams, which seems problematic for the
same reason.
Finally, the object passed to the error callback/event currently only
has a PERMISSION_DENIED error code. It might be worth investigating the
need for other codes like PERMISSION_REVOKED, DEVICE_REMOVED, etc. as
well, to handle the case where permission was granted, but then the user
later changed their mind or unplugged the device. (It's possible that
the proposed ondisconnect event in the event model could be handled as
an error event with an appropriate code, though I'm not sure if that's
better or worse than separate event.)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Stream API Feedback
On 2011-03-14 17:59, Lachlan Hunt wrote:
There are a few issues with the recently added media streaming API.
In addition to what I sent previously, there are some additional use
cases that do not appear to be addressed adequately by the current spec
for streaming media.
In chat clients, like Skype, it's common for users to be able to adjust
the microphone volume or mute the audio stream, or to enable or disable
the video stream, without interupting the call. However, the
GeneratedStream interface only provides a very simple API to pause,
resume or stop the entire stream, and not individual tracks within the
stream.
e.g.
var stream;
navigator.getUserMedia(audio,video, success);
function success(s) {
stream = s;
// ... Code to make P2P connection for video chat
}
In this case, stream.pause() will pause both the audio and video
streams, whereas the user, for example, may just temporarily want to
pause the video stream, leaving the audio enabled.
While it may be possible for the browser to allow such control entirely
from the browser chrome, independently of the page, the page author may
wish to provide customised controls for these features. I believe the
API should be adjusted to allow the individual tracks within a stream to
be paused or resumed independently of each other, and for there to be
some way to adjust or mute the microphone volume.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] device use cases
On 2011-03-15 14:10, jesp...@opera.com wrote: I just heard that device was canceled and replaced by navigator.getUserMedia()... Just wanted to point out a couple of use cases that I was looking forward to, that seems to maybe have gotten a bit lost on the way? I was really looking forward to start playing around with USB MIDI interfaces to control my synth and maybe even do really creative stuff the other way around. Just imagine being able to play on your synth (or any other device with MIDI output) and generate sound or graphics in a canvas web application or so! It may be possible to address these use cases using an API based approach in the future, which will be better than the element based approach of device, but at this stage it is better to keep things simple and focus on just audio and video for now. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Stream API Feedback
Hi, There are a few issues with the recently added media streaming API. The IDL for GeneratedStream should indicate that it inherits from the Stream interface. The API includes both readystatechange event, as well as independent events for play, paused and ended. This redundancy is unnecessary. This is also inconsistent with the design of the HTMLMediaElement API, which does not include a readystatechange event in favour on separate events only. The API does not provide any way for the author to indicate a preferred camera. Some devices include multiple cameras, particularly phones with front and rear facing cameras, and some use cases are better suited to one or the other. For example, an augmented reality application that takes advantage of geolocation and device orientation in order to overlay the video stream with things (e.g. push pins to identify points of interest, like on Google Street View). Such an application would be better suited for working with the rear facing camera. But with a video conferencing application, the front facing camera would be more suitable. It might therefore be useful for the author to provide a hint to this effect, which would allow the UA to more intelligently select the default camera for the user. There are some use cases for which it would be useful to know the precise orientation of the camera, such as augmented reality applications. The camera orientation may be independent of the device's orientation, and so the existing device orientation API may not be sufficient. In the simple case, the front and rear cameras face in opposite directions, and so if an augmented reality application was built assuming it was using the rear camera, but the user instead granted access to the front camera, the calculations would be 180˚ out. Some devices may also provide cameras that may allow the camera to be rotated independently of the device itself, and so camera orientation information would need to allow for this. I don't know the best way to provide this, and there likely to be issues about whether the camera orientation should be relative to the device itself, or relative to fixed Earth coordinates (North, East, Up), like the existing device orientation API. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
On 2010-07-08 19:18, Diego Perini wrote: On Thu, Jul 8, 2010 at 4:03 PM, Lachlan Huntlachlan.h...@lachy.id.auwrote: As a workaround, you can use AdBlock in Firefox to block the offending script. Just manually add this URL to your block list. http://www.whatwg.org/specs/web-apps/current-work/status.js The problem is not only with Firefox and it happens I am not only using Firefox. Is there a similar blocking feature of Opera that you can suggest ? Opera includes a Content Blocker feature by default. See Block Content... in the context menu. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
On 2010-07-08 02:28, Garrett Smith wrote: This is about the fourth time I've said it here. Can the person in charge of writing the slow and buggy ajvascript on the HTML 5 spec please remove that? The problem is that that whatwg page causes freezes and crashes in Firefox. i As a workaround, you can use AdBlock in Firefox to block the offending script. Just manually add this URL to your block list. http://www.whatwg.org/specs/web-apps/current-work/status.js -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] More YouTube response
On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] More YouTube response
On 2010-07-02 21:01, John Harding wrote: On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use... I would still, however, argue against anything of the sort being added to WebM... I think it's unavoidable that the functionality of thevideo tag in some browsers will be extended by various add-ons to the browser. Right, as I said, it's possible. But that doesn't mean we should support it in any way. YouTube would do better to address this issue by bringing the major players in the content industry to the table to discuss methods of publishing their content in interoperable ways without DRM. As Henri pointed out, major content producers already broadcast their TV shows and movies over the air without DRM. Although the BBC iPlayer uses DRM for the desktop version, they broadcast the show DRM free over the air and they make DRM free content available to the iPhone. People have even found ways to access that from other devices too. So the DRM really isn't there to protect the content. It's just to force users to use the BBC's own iPlayer software, rather than letting users use their own choice of software. The industry even releases content on DVD knowing that the DRM is completely ineffective, because they only use it so they can control the DVD player market, rather than actually doing anything practical about illegal copying. The music industry have already largely dropped DRM. Even Spotify, which does use DRM, permits the open source application deSpotify that bypasses the DRM to continue unimpeded for premium subscribers. (The developers opted not to work around the blocks placed on free accounts though). It's all about the business model. The industry thinks they need their DRM so they can hold onto the same business model they've had for years, without adapting. That's why they've gone to court over every new innovation in the last 50 years, before slowly catching up. The truth is they don't need DRM, as so many independent content producers are demonstrating. YouTube and other video streaming sites just needs to push them to accept a reasonable and fair business model that will work. Make it easy for users to stream the content, and even easier for users who want to buy and download the content legally. Users currently go to torrent sites because it's easier than fighting with the industry to get what they want. Make it easier to do the right thing. Don't punish the legitimate them with DRM, while the pirates get away with a better user experience. Give users a real reason to buy, and they will. e.g. Make the purchased content have a higher bit-rate and resolution, surround sound, no ads, no visible logo watermark, and/or other added features. Provide some incentive, maybe a reward system that benefits the subscribers in some tangible way. Do whatever you do to find a business model that works; just say no to DRM. It's not needed. The big content industry knows that, they just won't admit it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] input type=upload (not just files) proposal
On 2010-06-08 16:37, Simpson, Grant Leyton wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
On 2010-06-02 13:05, Ashley Sheridan wrote:
On Wed, 2010-06-02 at 12:51 +0200, Oldřich Vetešník wrote:
I'm missing the wrap=off value for textarea wrap attribute; is there any
particular reason why this is not part of HTML5?
Currently the only values mentioned are soft and hard:
http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap
The explanation is here.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html
In theory, you can achieve the same effect by using CSS.
textarea { white-space: nowrap; }
This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.
That does seem odd. I would have thought the default value would be
'off' or 'no' as I've never seen a browser yet wrap text in a textarea
unless a specific wrapping method was specified either via an attribute
or CSS.
Netscape 4 was the last browser I'm aware of that defaulted to that
wrap=off behaviour. I believe every other mainstream browser I'm aware
of since then wraps by default.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] audio and video: volume and muted as content attributes?
On 2010-06-01 13:09, Bjartur Thorlacius wrote: On 5/31/10, Silvia Pfeiffersilviapfeiff...@gmail.com wrote: I am not aware of a CSS property for media elements that lets you control the muted state. Can you link me to a specification? Well, http://www.w3.org/TR/CSS2/aural.html defines volume and play-during. Play-during can stop, autoplay and repeat sounds. It's not obvious to me how this will apply to elements that represent audiovisual content but volume: silent; unambiguously mutes content. Those properties were designed for aural browsers using speech synthesis to read the content of a page, not to control multimedia in a page itself. Also, attempting to hijack those properties for use with multimedia content could create difficulties as you would have to define how the HTMLMediaElement's volume and muted properties interact with those CSS properties, if at all. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] On implementing videos with multiple tracks in HTML5
On 2010-05-23 05:40, Carlos Andrés Solís wrote: Imagine a hypothetical website that delivers videos in multiple languages. Like on a DVD, where you can choose your audio and subtitles language. And also imagine there is the possibility of downloading a file with the video, along with either the chosen audio/sub tracks, or all of them at once. Right now, though, there's no way to deliver multiple audio and subtitle streams on HTML5 and WebM. Since the latter supports only one audio and one video track, WebM, just like Matroska, certainly does support multiple video and audio tracks. The current limitation is that browser implementations don't yet provide an interface or API for track selection. Whether or not authors would actually do this depends on their use case and what trade offs they're willing to make. The use cases I'm aware of for multiple tracks include offering stereo and surround sound alternatives, audio descripitons, audio commentaries or multiple languages. The trade off here is in bandwidth usage vs. storage space (or processing time if you're doing dynamic server side muxing). Duplicating the video track in each file, containing only a single audio track saves bandwidth for users while increasing storage space. Storing all audio tracks in one multi-track webm file avoids duplication, while increasing the bandwidth for users downloading tracks they may not need. The latter theoretically allows for the user to dynamically switch audio tracks to, e.g. change language or listen to commentary, without having to download a whole new copy of the video. The former requires the user to choose which tracks they want prior to downloading the appropriate file. If there's only a choice between 2 or maybe 3 tracks, then the extra bandwidth may be insignificant. If, however, you're offering several alternate languages in both stereo and surround sound, with audio descriptions and directors commentary — the kind of stuff you'll find on many commercial DVDs — then the extra bandwidth wasted by users downloading so many tracks they don't need may not be worth it. with no embedded subtitles, Timed text tracks within WebM (most likely WebSRT) will eventually be supported. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Installable web apps
to be in
HTML5.
bb type=makeappInstall application/bb
http://www.w3.org/TR/2009/WD-html5-20090423/interactive-elements.html#the-bb-element
Another alternative would be to use a link relationship perhaps link to
either a manifest or to the URL of the application itself.
e.g. a href=htts://mail.google.com/mail/ rel=application.
This could work analogously to rel=sidebar, where some browsers
recognise that and prompt the user to load the link in their sidebar.
Although, in this case, it could prompt the user to install the app instead.
// myapp.json
{
name: My Application,
icons: ...,
urls: [
reader/
],
permissions: [
...
]
}
I wonder if there would be a way to integrate this extra information
into the existing cache manifest file, or into the HTML with meta and
link elements, rather than creating a whole new manifest file format.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Dealing with Stereoscopic displays
On 2010-04-27 00:59, Robert O'Callahan wrote: I think it's interesting to think about what browsers could do with stereo output. We already have three features that could produce useful stereo output today: 1) WebGL 2) CSS 3D Transforms 3)video (assuming there was some kind of 3D video format defined elsewhere) Of those, I think 3D video is perhaps the most significant, followed by WebGL for, e.g. 3D games. But I don't think these are issues that should be addressed by the WHATWG or HTMLWG at this stage, particularly for video. 3D video would depend on the availability of a suitable 3D video codec that can be implemented by browsers. Something like h.264 MVC (Multiview Video Coding) as used by 3D Blu-ray would be nice, but we would need something that is royalty free. I don't know of any other 3D video codec, especially not among the royalty free choices. I think this issue should be revisited in the future if and when such a codec becomes available. But given that the the actual video rendering is handled by the implementation, completely transparently from the DOM API, the current markup and DOM API should be sufficient for basic playback support. 3D Enhancements to the DOM API and markup can be considered later if necessary, such as figuring out how to deal with drawing an HTMLVideoElement playing a 3D video onto a 2D canvas. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Two propositions for the autofocus attribute
On 2010-04-16 09:30, Kit Grose wrote: On 16/04/2010, at 5:06 PM, Markus Ernst wrote: Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting. What if the form is received via XHR as HTML and simply injected to the page using innerHTML? If the user has already started interacting with other controls in the page, like form controls, a contenteditable region or is typing into some control in the browser chrome (e.g. the address bar or quickfind textbox), the autofocus behaviour should not occur. Otherwise, if the user hasn't interacted with the page, then the control should be focussed. Personally, I also agree that it makes sense for autofocus to only apply to the first such control. However, Opera's implementation currently works as specified in the spec, focussing the last such control that is inserted. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Kornel Lesinski wrote: However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: sandbox-$token.../sandbox-$token where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: $token:sandbox xmlns:$token=…/$token:sandbox No, you couldn't use a namespace like that, because then the sandbox element would not be in the HTML namespace, and thus would not have any known semantics. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Lachlan Hunt wrote: Kornel Lesinski wrote: However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: sandbox-$token.../sandbox-$token where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: $token:sandbox xmlns:$token=…/$token:sandbox No, you couldn't use a namespace like that, because then the sandbox element would not be in the HTML namespace, and thus would not have any known semantics. Um, ignore me. I'm just not thinking properly today. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Question about header and footer
Bruce Lawson wrote: Is it permissible for one element to have more than one child headers, or more than one child footers? Yes. And, if is permissible, should it be? Unless we have a very good reason, I don't think we should start placing arbitrary restrictions on how elements can be used. In fact, there's a very good reason to allow footers to be used more than once per section, as illustrated by the first footer element example in the spec. I don't believe it's a problem for multiple headers either as the sectioning algorithm will create implied sections from the headings anyway. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] figureimg* caption
Philip Jägenstedt wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. Yes, I expect we'll see a lot of authors get them reversed, using the dd for the caption if they want the caption below the content. This is likely to occur since existing authors have already learned that dt comes before dd when used within a dl, and because old habbits die hard, they're likely to repeat the pattern within figure. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) Some additional reasons why using dt/dd in figure is a bad solution: The simplest workaround presented so far to solve the styling issue in IE is basically to do this: div class=figure figure ddimg src=image alt=.../dd dtCaption/dt /figure /div And then rather than style the figure itself, give some style to the div because some styles don't work properly when applied to the figure. This effectively makes the figure element itself entirely useless, especially given that all browsers lack support for it. It would be far easier for authors to just stick with this entirely hack free alternative that doesn't use the new elements: div class=figure img src=image alt=... p class=captionCaption/p /div At least until browsers actually implement support for figure and IE6/7's market share becomes negligible. It will take a couple of years for those events to occur, and there's no need to rush into using the new elements yet. The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure I was the first one to suggest that on IRC a while ago, but I'm not convinced it's a good idea. Although it's certainly better than using dt/dd. See IRC logs here. http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525 http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133 The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. Limiting the caption attribute to just the p element, or just div or something, might help, but I'd still expect authors to end up using it on other elements anyway. There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. Since Hixie is adamant that introducing a new element for the caption isn't going to happen, and I've yet to find a way to convince him otherwise, that leaves us with legend. Although legend has it's own styling issues in browsers, these will eventually be resolved in a couple of years. Therefore, the best solution is to revert the spec back to using legend for figure, but strongly discourage authors from using these new elements yet, until the implementation issues are resolved. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] figureimg* caption
Tab Atkins Jr. wrote:
On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
To some extent, it even makes it difficult for authors to provide reasonable
styles if they can't guarantee which elements content writers will choose
for their caption. Imagine designing a CMS template with some default
styles for figure and caption, the CSS in the template would have to deal
with so many possible element choices just for the caption, it'll be
difficult to get it right and test everything.
There are a multitude of reset style sheets on the web today that
don't seem to have a problem removing virtually all default styling
from elements. It would not be difficult to modify one to strip a
@caption element down to bare bones and then restyle as desired.
Applying reset styles alone and making all elements look the same
basically defeats the purpose of being able to use a range of different
elements, and is very likely not what an author would ultimately want.
Reset styles are just used to give different elements a more level
playing field for new styles, and so authors would then still have to go
through all the elements and style them appropriately for use as a
caption. Plus, authors have to worry about cascading issues from other
styles in their own stylesheets.
Say, for instance, an author had applied special styles to paragraphs in
some special type of section:
#foo p { margin-left: 1em; }
And then a content writer puts a figure in there using p caption, but
the CSS author failed to adequately account for figures being used in
that section, despite doing:
p[caption] { margin: 0; }
Due to specificity, the first rule would apply regardless and the
caption would get a potentially unwanted margin.
I know there are ways to work around the issue, such as using !important
or finding ways to increase the specificity of the latter selector, but
the point is that introducing unnecessary element clashes creates
needless complexities that should be avoided.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Use cases for the time element
Henri Sivonen wrote: On Nov 26, 2009, at 18:50, Jeremy Keith wrote: The following extract shows how an IM conversation log could be marked up. p time14:22/time begof/b I'm not that nerdy, I've only seen 30% of the star trek episodes What's the point of having the time semantically marked up in this example? What kind of processing scenario would benefit? It might be more valuable if the datetime attribute was used to give the date and/or timezone information. This is effictively what the IRC log for the #microformats channel does. http://rbach.priv.at/Microformats/IRC/2009-11-27 That would allow, for example, user scripts to automatically convert times in the chat log to local times. It could also be used for styling purposes, so it can be styled differently to distingish it from the rest of the line. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] article/section/details naming/definition problems
Erik Vorhes wrote: On Wed, Sep 16, 2009 at 3:35 AM, Bruce Lawsonbru...@opera.com wrote: there would also need to be acomment element I'd be *slightly* concerned that confusion could arise between a comment element and the!-- comment syntax --, at least in discussion. (I.e., what would HTML comment mean?) We couldn't use a comment element anyway for backwards compatibility reasons. IE does some weird stuff when parsing it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Date/time field types - min, max, popup UI.
Sigurd Magnusson wrote: I see that the spec does not appear to concern itself with the presentation of date pickers. This issue is probably best addressed within CSS, possibly by adding more suitable values to the 'appearance' property, or possibly even picking an appropriate rendering simply based on the 'height' and 'width' of the control, much like a type=range control switches from a horizontal to vertical slider if the width is narrower than the height. e.g. If the styling makes the dimensions too high for rendering as a drop down style widget, the UA could switch to a layout that shows the whole calander for a month or two instead of a drop down. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] A New Way Forward for HTML5
Manu Sporny wrote: Tab Atkins Jr. wrote: Problem: A Kitchen Sink Specification Ian recently implemented a way to hide or highlight the UA guidelines that confuse so many more casual readers. Does this help? (I know it helps me. ^_^) If I knew it existed it might have helped a bit. Even now that I know it exists, I can't figure out how to activate it. How do I hide the UA Requirements for: http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element It's just an alternate stylesheet, so you can select the Author documentation only style from your browser's menu. There is also a set of controls at the top of the specification that does that using JavaScript, and it also sets a cookie so the choice is remembered. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value for the presence of either a slash or backslash.
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] time
David Singer wrote: At 3:22 +0100 10/03/09, Charles McCathieNevile wrote: The other issue is the one of precision - while you can name a single year, which will deal with a lot of use cases there are a lot left out because the precision required is a period. Ranges are included in 8601, and making a range syntax that handled almost all the relevant use cases is pretty straightforward. Adding a range construct to 8601, or having a range construct ourselves using 2 8601 dates, seems like something we could ask for or do. ISO 8601 already has a syntax for durations and time intervals [1]. However, until we consider allowing the syntax to be used in HTML5, we still need to know the use cases and understand what problems would be solved by using the time element. So far, we've had vague use cases related to historians and time lines, and others relating to imprecise event dates. But there's been no clear description of the problems that need solving, nor any explanation of why they are significant enough to be addressed. I think the design principles that are applicable here include Solve Real Problems [2], and the proposed Baby Steps [3] principle (which still needs to be added to the design principles document). I think baby steps is particularly relevant here because we really shouldn't be attempting to solve every little problem. Yet that seems to be what some people are pushing for by asking for alternative calendar systems, better historical date support, durations and time intervals, without much regard for the complexity such features would introduce for both authors and implementers. In regards to contemporary dates, which are already supported, the problems solved by the time element include fixing the accessibility issue with hCalendar's use of the abbr element, and problems regarding ambiguity of regional date syntaxes. e.g. the date 04/02/09 means different things to different people depending on the conventions used in their country. By using the time element time datetime=2009-02-0404/02/09/time, the ambiguity can be solved by allowing UAs to expose the date to the user in a less ambiguous format. (Although, it would be better if people avoided such ambiguous dates, that doesn't seem too likely to happen with most people). Another potential problem solved is helping to distinguish arbitrary 4 digit numbers from years, so that screen readers can pronounce them correctly. e.g. If 1983 is meant as just a number, it should be pronounced as one thousand nine hundred and eighty three. But if it's meant as a year, then it's conventional to say nineteen eighty three instead. Although, I'm not certain if this is a real problem or not, I could be completely wrong about this. I've been told that screen readers have settings for this and possibly some limited heuristics for detecting if a given number is a year or not. [1] http://en.wikipedia.org/wiki/ISO_8601#Durations [2] http://dev.w3.org/html5/html-design-principles/#solve-real-problems [3] http://esw.w3.org/topic/HTML/DesignPrinciplesReview#head-98fea741b3ace0c8da87029864ec4a5db4b2358e -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] time
Bruce Lawson wrote: On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt lachlan.h...@lachy.id.au wrote: I think the design principles that are applicable here include Solve Real Problems [2], Real problems to be solved: 1) microformats have accessibility problems with abbr; time element solves that - but if the only valid use is to mark up future events (as Henri suggests), then pages become invalid as they age. (Much like me, actually) Future events are not the only valid use of the element. It already supports dates back to 0001-01-01, which covers a significant proportion of historic dates already. It's just not really optimised for such uses. 2) microformats are already used in the wild to mark up past events. sometimes ancient and sometimes without DDMM precision. People who wish to do that won't be able to use time, so it perpetuates the accessibility problems it wishes to solve and fragments the way dates are marked up on the Web; some will use time, some will use microformats Yes, examples of such imprecise dates using microformats have already been provided for those, which is a good start, and personally I think allowing support for years only () or year and month only (-MM) dates is a reasonably easy thing to do. But the issue still needs further investigation to understand what useful functionality consumers would gain from such markup. Specifically: * Investigation of how it would help users of assistive technology to have imprecise dates marked up. (I mentioned one potential benefit in my last email, but, as I said, I'm not certain about it and it needs research to confirm it). * Investigation of how browsers could expose the date to to users in a useful way, and an understanding of how and why this would be useful for such historic and/or imprecise dates. * Investigation of other potential consuming applications, such as - The SIMILE timeline application that can create timelines from marked up events in a page; - Date based news searching applications (e.g. searching for news from a particular time period). * Investigation of how imprecise dates affect the ability to import such events into a calendar. e.g. The Sydney Royal Easter show scheduled for 2009-04, and takes place over a period of a few weeks in the month. Is it enough to simply say: time datetime=2009-049–22 April 2009/time Or would it be better to give the precise date range, as time datetime=2009-04-099/time–time datetime=2009-04- April, 2009/time Or would supporting a range directly in the datetime field support this better: time datetime=2009-04-09/2009-04-229–22 April 2009/time Investigating how hCalendar currently addresses use cases like that would be useful in order to address some of the limitations that approach may have. Another case for an imprecise date might be: ptime2009/time is The International Year of Astronomy./p For this, we would need to understand what real benefit consuming applications would gain from that. It's not really a date that someone would want to import directly into their calendar. But understanding what other potential applications, such as those mentioned above, might want to do with it would be useful. What advantage is there for authors and consumers by *not* extending the range of dates that can be described with time ? That's the wrong question to ask because it places the burdon of proof on the wrong side. But by not addressing every possible little use case under the sun, we keep the language simplified and easier for authors to learn and use, and we can focus on really optimising for the top ~80-90% of the use cases, without spending a disproportionate amount of time trying to optimise for the remaining ~10% of edge cases too. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Historic dates in HTML5
Bruce Lawson quoted Andy Mabbat: Andy Mabbett has already listed use cases http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639.html ... They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. It's not clear how such a timeline would make use of the time element and I couldn't find any use of microformats on that page. Could you please elaborate on the relevance of that page in regards to this issue? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] section element example
Rikkert Koppes wrote: The example presented at the section element definition [1]. The given markup could be ok, however, with a look at the actual contents (a nice essay about apples), the h1 elements found in the section elements should actually be h2 elements, giving rise to the folowing document structure: Apples - Red Delicious - Granny Smith No, the example is correct. It's actually illustrating how you can use h1 elements in combination with the section elements to achieve the same structure. See the section on headings and sections and creating an outline for more info. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#headings-and-sections -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Dates and coordinates in HTML5
[Resending this to the list now that the problem that prevented it from accepting any mail has been fixed.] Andy Mabbett wrote: Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (find me all the pages about events in 1923 — recent developments in Yahoo's YQL searching API (which now supports searching for microformats): http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats.html have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. Neither of those appear to be using BCE dates, non-Gregorian calendars or imprecise dates. It's not clear how they are use cases for the features that you are asking for. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Dates and coordinates in HTML5
class=geo title=52.548;-1.932Great Barr/abbr Bruce and I agree that this could be resolved, and HTML5 usefully extended, by a “location element: location latitude=52.548 longitude=-1.932Great Barr/location I'm not familiar with the use cases for the geolocation microformat, nor am I aware if there even are any. So I will not comment on this. Using the “schema attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies): location schema=moon latitude=52.548 longitude=23.47297Sea of Tranquility/location What's the use case for this? Why would most people need to mark up lunar co-ordinates? Are astronomers really asking for such facilities to be included in HTML? Would we really be addressing their needs by doing so? Now all we need to do is to work-around the abuse of ABBR for durations, in the draft hAudio microformat: abbr title=PT3M23S3 minutes 23 seconds/abbr What's the use case? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Captions, Subtitles and the Video Element
Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. * Caption tags, when displayed, count as span class=caption.../span unless they have style associated with them (uncommon). So they can be tweaked via CSS. Whether by the author or overridden by useragent. I do not understand what you mean here. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] List Headers
Ian Hickson wrote: On Wed, 4 Feb 2009, Robert O'Rourke wrote: Are there any plans to bring list headers from HTML3 into HTML5? They'd make a lot of markup patterns simpler and be very very useful when it comes to styling. You can do this in HTML5, using figure and legend: figure legendA header for the list/legend ul liList item/li liList item/li liList item/li /ul /figure Since figure is a sectioning root, a heading element could also be used here and it wouldn't affect the outline. Please add an example of this use case to the spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] List Headers
Garrett Smith wrote:
On Wed, Feb 4, 2009 at 2:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
As an example of this, consider the element summaries in the HTML 5
Reference, the attribute list has the heading Attributes, but that heading
is not meant to affect the document's outline and doesn't appear in the TOC.
I had to use class=no-num no-toc, which is recognised by anolis (the
spec's pre-processor tool), to avoid it being included in the TOC.
http://dev.w3.org/html5/html-author/#the-elements
But note that the issue itself doesn't affect just lists. The same issue
occurs for the DOM Interfaces sections, but that content isn't marked up as
a list, and I'm also considering changing the attributes to use a table
instead of a list, providing the attributes and associated descriptions.
Is this what you are referring to:-
| h4 id=reflecting-content-attributes-in-dom-attributes
| span class=secno2.8.1 /spanReflecting content attributes in
| DOM attributes/h4
?
No, you're looking at the wrong document. I was talking about the
markup I used in the HTML Reference, not what's being used in the spec.
div class=attributes
h5 class=no-num no-toc id=attributes-1Attributes/h5
ul
lispanGlobal attributes/span/li
...
/ul
/div
div class=dom
h5 class=no-num no-toc id=dom-interface-2DOM Interface/h5
ul
li
pre class=idlinterface ... {
...
};/pre
/li
/ul
/div
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[whatwg] Semi-transparent content models
Hi, The spec defines the semi-transparent content model, but this is no longer used for any elements. Please remove this from the spec. http://www.whatwg.org/specs/web-apps/current-work/#transparent-content-models -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] embedding meta data for copy/paste usages - possible use case for RDF-in-HTML?
Hallvord R M Steen wrote: 2009/1/20 Jamie Rumbelow ja...@jamierumbelow.net: I think that the already available solution to your problem are Microformats - you are essentially embedding metadata, semantically in HTML. Of course, but I think your comment misses half of the proposed solution.. namely what format the UA puts the information on the clipboard in. Determining how one application passes information via the clipboard to another application seems very much out of scope of HTML. If there was such a method available, then we could investigate how to obtain the relevant semantics from the document. But we can't do that until there is some clipboard format available for this purpose that other applications can understand. I doubt that it would be possible to create some generic format that would be suitable for such a wide range of use cases. For an address book application, the most sensible approach would be to add a vCard format (text/directory;profile=vcard) to the clipboard. Given that many address books already support the vCard file format, it's not such a stretch to believe that they could read the data in that format from the clipboard. The problem is getting them to support an import from clipboard feature. However, other use cases, like pasting a quote into a word processor complete with bibliographic information, would need an entirely different format. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] embedding meta data for copy/paste usages - possible use case for RDF-in-HTML?
Hallvord R M Steen wrote: I'd like some way to add meta data to a page that could be integrated with the UA's copy/paste commands. These use cases are a good start, but the problem is that you've begun with the assumption that copy and paste would be a part of the solution. For example, if I copy a sentence from Wikipedia and paste it in some word processor, it would be great if the word processor offered to automatically create a bibliographic entry. Do you mean a bibliographic entry that references the source web site, and included information such as the URL, title, publication date and author names? That could be a useful feature, even if it could only obtain the URL and title easily. Often, when writing an article that quotes several websites, it's a time consuming process to copy and paste the quote, then the page or article title and then the URL to link to it. An editor with a Paste as Quotation feature which helped automate that would be useful. HTML5 already contains elements that can be used to help obtain this information, such as the title, article and it's associated heading h1 to h6 and time. Obtaining author names might be a little more difficult, though perhaps hCard might help. If I copy the name of one of my Facebook friends and paste it into my OS address book, it would be cool if the contact information was imported automatically. Or maybe I pasted it in my webmail's address book feature, and the same import operation happened.. I believe this problem is adequately addressed by the hCard microformat and various browser extensions that are available for some browsers, like Firefox. The solution doesn't need to involve a copy and paste operation. It just needs a way to select contact info on the page and export it to an address book. There are even web services that will parse an HTML page and output a vCard file that can be imported directly into address book programs. If I select an E-mail in my webmail and copy it, it would be awesome if my desktop mail client would just import the full E-mail with complete headers and different parts if I just switch to the mail client app and paste. Couldn't this be solved by the web mail server providing an export feature which let the user download the email as an .eml file and open it with their mail client? Again, I don't believe the solution to this requires a copy and paste operation. However, I'm not sure what problem you're trying to solve. Why would a user want to do this? Why can't users who want to access their email using a mail client use POP or IMAP? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] HTML 5 : Misconceptions Documented
Mike Wilson wrote: Ian Hickson wrote: On Sat, 17 Jan 2009, Mike Wilson wrote: So I wonder what is your process for determining if a quirk should be included in HTML5 or not? It basically boils down to did Web browser vendors find that if they didn't implement it, enough people complained to justify spending the resources to implement it after all?. Ah, so your process is really to look at if browser vendors historically have added special handling for individual quirks and then mimic popular solutions in the spec? For some things, yes. Now I am just being curious ;-) but how on earth do you find all quirks (and if they have been specially dealt with) - is it up to reports on the mailing list or are you reading source code? :-) Some things are known based on experience, because they occur so freqently in practice. But in general, when trying to spec a particular feature, a lot of time is spent testing and reverse engineering it using a variety of techniques including black box testing, reviewing past bug reports or even looking at the source code of the open source browsers. For some examples of this, take a look at these articles http://ln.hixie.ch/?start=1037910467count=1 http://ln.hixie.ch/?start=1137799947count=1 http://ln.hixie.ch/?start=1155195074count=1 http://ln.hixie.ch/?start=1158969783count=1 http://ln.hixie.ch/?start=1161042744count=1 http://ln.hixie.ch/?start=1161121410count=1 And do you generally find concensus among the non-MS vendors or are there many quirks that are only worked around in a single browser, and how do you handle that? If possible, we try to spec the behaviour that has the most interoperability among the browsers. i.e. If 3 out of 4 browsers do A, and the the other does B, and there's no significant evidence of compatibility problems with A, then the spec is likely to define A. If there's no interoperabiliy at all between the browsers (i.e. All browsers do something completely different), then we have a little more freedom to pick the most sensible alternative, taking into account any compatibility issues with real world content. The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). Do you think this will happen with the current popular browsers, ie will they actually remove existing code that implements workarounds that don't make it into HTML5? Or will they employ some legacy vs HTML5 mode switching where their custom workarounds are only in legacy mode? If the spec omits something that we implement and there's evidence to suggest that we need to keep it for compatibility, then we'll try to get that added to the spec. If it's something minor that no other browser does and it doesn't appear to be needed for compatibility with anything, then we're more likely to drop it. There will not be, at least in Opera, Firefox or Safari, new modes added beyond the existing no quirks, limited quirks and quirks modes. I guess what I am really thinking about is whether there will ever be a strict to standard HTML5 implementation, or a reference implementation, that stays exactly on what is written in (or easily interpolated from) the HTML5 spec...? There won't be any implementation considered to be the reference implementation. But the hope is that all implementations will eventually converge on implementing things in the same way, and that the spec will match. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] HTML 5 : Misconceptions Documented
Mike Wilson wrote: Lachlan Hunt wrote: There will not be, at least in Opera, Firefox or Safari, new modes added beyond the existing no quirks, limited quirks and quirks modes. Do you reckon all, or only some of, these modes will implement the HTML5 spec? (and differ only in css/rendering) As far as the HTML quirks are concerned, they will all hopefully be specced. The three modes are defined in the spec already and many of the quirks have already been documented, or are at least mentioned as an issue in the spec. See this section: http://www.whatwg.org/specs/web-apps/current-work/#no-quirks-mode Some of the rendering quirks may be addressed in the rendering section of this spec, though it would be nice if the CSS WG would document a lot of the relevant issues themselves. However, I don't believe they have any plans to do so at this stage. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Extracted content element.
Jamie Rumbelow wrote: Is there a need for a tag in HTML5 to specify extracted content semantically, such as the first few paragraphs of a blog post. The extract tag could optionally contain a href attribute to the full version of the content. This is a clear example of presenting a solution and asking if there is a problem for it to solve. Generally it is better to begin by outlining the problems and use cases that you believe aren't adequately addressed, which makes it a lot easier to determine whether or not existing markup is suitable, develop an appropriate solution if needed, or determine that it's not worth addressing. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] usemap= and related issues
Ian Hickson wrote: On Mon, 1 Dec 2008, Jonas Sicking wrote: Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks mode things spread into code that I work on ;) ). If no other browser is doing it in standards mode either I'm more than happy to not have it in the spec. The spec is including quirks-mode requirements; do other browsers do it in quirks mode? As I already said above, neither Opera, Safari or IE8 have the same behaviour. I tested both quirks and standards mode. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. I'm having a hard time seeing how this is a use case for video and not for img. If one wants the intrinsic width/height to be used, then simply don't set width/height. Otherwise, just setting just one of width/height or using CSS max-width/max-height should do the trick. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. img src=circle.jpg width=400 height=400 !-- circle -- img src=circle.jpg width=400 height=300 !-- oval -- I think it would be much more consistent if these elements behaved in the same way. What is the use case for wanting a video to be stretched? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: The use case for stretching moving images (video) is exactly the same as for stretching animations (img src=animation.gif) or static images (img src=static.jpg). Consistency is not a use case. For images, we're constrained by backwards compatibility requirements to stretch them, rather than keep aspect ratios, regardless of what use cases there may or may not be for doing so. For video, we are not constrained by such backwards compatibility and we have the opportunity to specify the most rational alternative as the default. While I think that fixing incorrect aspect ratio is the most probable use, consistency and generality is the real issue here. Given that the pixelratio attribute was dropped in part due to a lack of compelling use cases, I don't think the same use case will be compelling for this either. If there are real use cases for stretching video, then they should be judged on their own merits, rather than just falling back to the consistency argument. With an image of size 800x600 it's possible to display at any size, even those which don't match the aspect 4:3. With moving images (video) we can't influence it at all. The previous solution was the pixelratio attribute, but I have 2 other possible solutions: video src=4x3.mpg width=1920 height=1080 keepaspect The video would be pillarboxed. Retaining the aspect ratio needs to be the default because based on experience with video on the web today, e.g. on YouTube, and also based on the behaviour of common media players, like VLC, QuickTime, Windows Media, etc. When a user resizes their video player, the video generally maintains the aspect ratio and gets black bars; (or in QuickTime's case, the window size is constrained by the video's aspect ratio). There are menu options in VLC, and possibly others, to set the aspect ratio of a video to a selection of common aspect ratios, but there is no arbitrary scaling (at least, not that I'm aware of). video src=4x3.mpg width=1920 height=1080 The video would be stretched and have incorrect aspect And if a user chooses to put the video in full screen, then what? Should it maintian that incorrect aspect ratio? Should it stretch to fill the whole screen, regardless of what type of monitor the user is using, or should it use the video's default aspect ratio? Given the number of people who watch 4:3 video stretched to a 16:9 display without even noticing/caring that the aspect ratio is wrong, While I'm aware that there are such people, largely because they don't know how to configure their TV's properly or because their TV's are broken by design, there are many others who do notice the difference (including myself). From my experience, stretching a 4:3 picture to fill a 16:9 screen is enough to make people on the screen look weird and out of proportion. It's less noticeable with cartoons, but in general, it's very noticeable and annoying. We should inflict such annoyances upon end users if it avoidable; at least not by default. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] usemap= and related issues
Jonas Sicking wrote: Ian Hickson wrote: On Thu, 26 Jun 2008, Jonas Sicking wrote: What I did notice in our code though is how we deal with the case when there are multiple maps with the same name. In this case we generally use the first map. But if the first map is empty, we use the first non-empty map. This was done for compatibility with some sites. See https://bugzilla.mozilla.org/show_bug.cgi?id=264624 I have no idea if this matters today or not. I couldn't reproduce this behavior. Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Kinds of Content
Lachlan Hunt wrote: http://www.whatwg.org/specs/web-apps/current-work/#kinds-of-content In the list of categories near the beginning of that section, it includes Form control content. But this isn't mentioned or described anywhere else in the spec. Is its inclusion in the list intentional or is it a mistake? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Issues relating to the syntax of dates and times
Pentasis wrote: Ian Hickson wrote: On Tue, 25 Nov 2008, Pentasis wrote: The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such. I agree with this, so disregard my previous remarks on this subject. I would however recommend dropping the word primary. Note that what you've quoted was from a note about a potential issue with the DOM APIs which appears in the last formally published WD, but which has since been removed from the current editor's draft. I wouldn't want to make people think their particular use case was excluded. What if someone wanted to use a date to indicate the time an entry was added, for instance? Hence the word primary. This confuses me again ;-) Sorry. Are you saying that examples and use-cases will be excluded from the spec? No. It's just that the note didn't list all possible use cases and that there are other similar use cases for marking up contemporary dates which are equally valid. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Interactive Content
The definition of Interactive Content states: Certain elements in HTML have an activation behavior, which means the user agent should allow the user to manually trigger them in some way, for instance using keyboard or voice input (though not mouse clicks, which are handled above). It's not clear which section the last statement in parenthesis is referring to. I couldn't find anywhere above that in the spec that discusses the handling of mouse clicks. Please add a link to the appropriate section. http://www.whatwg.org/specs/web-apps/current-work/#interactive-content-0 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Kinds of Content
Hi, All elements currently defined to be in the heading content category (h1-h6 and header) are also included within the flow content category. It seems that it would be easier and more consistent to state the definition of heading content that: All heading content is also flow content. Any content model that expects flow content also expects heading content. And then remove Flow content from category lists for those elements, as it would be implied by Heading content. Additionally, to improve readability, it would be useful to add a note to the definition of flow content that it includes all of heading content, phrasing content and embedded content; and a similar note in the definition of phrasing content that it includes embedded content. Finally, it would be useful if the spec eventually included some kind of diagram that illustrated the relationships between each of the categories. http://www.whatwg.org/specs/web-apps/current-work/#kinds-of-content -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Deprecating small, b ?
Nils Dagsson Moskopp wrote: The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. To me these look like the last remnants of the font element. So why are these elements retained ? This issue has been discussed in depth in the past; most significantly on public-html around May 2007. http://lists.w3.org/Archives/Public/www-html/2007May/thread.html#msg3 (I think most of the releant discussion is in the Cleaning House thread) I have added an entry to the FAQ detailing the rationale for including these elements, and have previously written an article about the issue too. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F http://lachy.id.au/log/2007/05/b-and-i http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Absent rev?
Martin McEvoy wrote: From the real world found here: http://nfegen.wordpress.com/2008/03/28/micrordformats/ pI read an interesting post recently, a href=http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html; title=Link to Mark Birbeck blog post‘So how about using RDFa in Microformats?’/a/p An explicit one way relationship I might like to add to the hyperlink above may be rev=reply a rev=reply href=http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html; title=Link to Mark Birbeck blog post‘So how about using RDFa in Microformats?’/a It seems the real world example you point to doesn't actually use such a relationship, so I don't see how it qualifies as being real world example in this case. In any case, if there was a real use case for such a relationship, then it rel=reply-to would seem to be more appropriate. It's meaning would then be roughly analogous to that of the In-Reply-To email header field. (Although, I'm not convinced that there is a use case that really needs solving here, and speculating about the use of hypothetical relationships doesn't really provide any compelling evidence in support of the rev attribute.) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Tri-state checkboxes
Hi, There's been some previous discussion about providing a way to support tri-state checkboxes, and I recently came across a feature that's supported in IE and WebKit for this purpose. The DOM property HTMLInputElement.indeterminate is supported for input type=checkbox http://msdn.microsoft.com/en-us/library/ms533894(VS.85).aspx There doesn't seem to be any corresponding content attribute supported by either. This was apparently also considered and rejected by the DOM2 WG several years ago. http://lists.w3.org/Archives/Public/www-dom/2002AprJun/0106.html http://www.w3.org/2001/12/DOM-Level-2-issues#i24 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr. wrote: I'd suspect that *all* examples where placeholder text is used (definitely all the examples I know of personally) are most semantically served by a label with the text. Iirc, I once saw a nice javascript solution that mutated the DOM to remove the label and use its text as a placeholder. Thus, I think this is best served by a CSS directive that does exactly that. External vs placeholder text is a display issue - semantically, both are labels for the field. I found real example that uses both a label and placeholder text. In the iPhone, the dialog for setting up a new e-mail account, contains four fields, each with a label and an example provided as placeholder text. These are: [Label] [Placeholder] Name:John Appleseed Address: [EMAIL PROTECTED] Password:Required Description: My Email Account -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can AUDIO/VIDEO element have a balance attribute
Biju [EMAIL PROTECTED] wrote: Can AUDIO/VIDEO tag have a balance attribute like? http://developer.mozilla.org/En/HTML/Element/Bgsound What's the use case you're trying to address or the problem you're trying to solve with it? It seems to me that the correct way for an author to handle balance is within the audio file itself, or for the user to adjust their own sound system preferences, as needed based on their environment/equipment. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag : loop for ever
Michael A. Puls II wrote: On 10/14/08, Ian Hickson [EMAIL PROTECTED] wrote: To be honest I'm not really convinced we need the looping feature at all. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. Whenever I come across an awesome video with an awesome song, I'll loop it for hours. I'll even loop it while I sleep. When it comes to playlists, I loop them too. That would be a use case to consider for a browser providing looping functionality for the user, possibly activated through the context menu or something. But it is not a use case for providing authors with the ability to loop automatically using attributes. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag : loop for ever
Eric Carlson wrote: As we discussed on IRC today, I think a valid use case for looping is background audio. It is possible to implement looping from script, but as someone else in this thread commented, it will be very difficult to do cleanly (eg. without artifacts). If this was done as some sort of background music for a game, then that's reasonable. There are many games that play annoyingly repetitive music. Having said that, I don't think that loopstart and loopend will be used frequently enough justify inclusion in the (first version of the) spec. Agreed. I think it's worth nothing that, according to Mozilla's documentation, the bgsound element uses a loop attribute uses a loop attribute that takes a number or the keyword infinite. The documentation for IE on MSDN is, however, quite vague about what values the attribute accepts. http://developer.mozilla.org/En/HTML/Element/Bgsound http://msdn.microsoft.com/en-us/library/aa454504.aspx -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] input=datetime and unixtime?
Tab Atkins Jr. wrote: I did some searching through the archives, but didn't find anything at all that talked about this. Out of curiousity, was there a reason that datetime doesn't store/send it's value as a unix timestamp? IIRC, one reason is or better graceful degradation in legacy user agents that don't support the datetime controls, and where no JavaScript based alternative available. In such cases, it's easier to get the user to enter a date in the format like -MM-DD, than it is to have them calculate and enter the number of milliseconds since the epoch. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Define Authoring Requirements for Duplicate Attributes
Hi, In the Writing HTML Documents section, under Attributes, the spec should state that attribute names need to be unique for each element, and that duplicate attributes are an error. Currently, this is only stated in the parsing algorithm. http://www.whatwg.org/specs/web-apps/current-work/#attributes1 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Timing for the poster image appearing for video
Adele Peterson wrote: The spec currently states that the poster image specified in the poster attribute for video can show up either when no video data is available or when a video element is paused and the current playback position is the first frame of video. The second situation seems like it would allow the poster image to be displayed when a user rewinds the video back to the beginning while paused. Looking at the way YouTube videos work when they're not set to autoplay, the poster frame is displayed up until the video begins playing for the first time. After that, it always displays whatever frame it's paused on, until it reaches the end and displays related videos instead. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
Michael A. Puls II wrote:
Anyway, the use case for .value is:
...
pFile to attach: p
pinput type=file
onchange=document.getElementsByTagName('p')[0].innerHTML +=
this.value;/p
...
How is that a use case? Please explain why outputting the value of the
control in an adjacent paragraph is useful at all and why authors would
do it. The value is visible in the control itself, so that seems
unnecessary.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
Adele Peterson wrote:
I'm looking at the Web Forms 2 specification for the multi-file
upload control that uses the min/max attributes. When multiple files
are selected, its unclear what the value attribute should contain.
Assuming you're referring to the value DOM attribute, not the value=
content attribute, It seems to be unclear what the value should contain
even when there's only a single file selected.
I did some testing to see what each returned. All tests use this markup
to obtain the value, using the Live DOM Viewer:
!DOCTYPE html
input type=file id=test size=100
input type=button onclick=w(document.getElementById('test').value);
value=Read Value...
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E
In each one, I selected a file named test.txt from within my home or My
Documents directory. These are the vaules returned in each browser:
Windows browsers:
IE 8: test.txt
IE 7 mode:test.txt
Firefox 2:D:\My Documents\test.txt
Firefox 3:test.txt
Opera 9.5:C:\fake_path\test.txt
Safari 3.1.1: D:\My Documents\test.txt
Mac browsers:
Firefox 3:test.txt
Opera 9.5:C:\fake_path\test.txt
Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
It could contain just the first filename, or a comma separated list
of all of the filenames. I think it will be useful though to add
something about this in the specification for consistency.
Opera 9.5 supports multiple file selection when a max= attribute is
set to a value greater than 1. It currently only returns the fake path
of the first file, as shown above. However, the control displays to the
user the real paths of all files selected as quoted strings separated by
semi-colons. e.g.
/Users/lachlanhunt/test.txt;/Users/lachlanhunt/other.txt
Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
refuses to return the real path anyway, maybe we should define that when
there's only a single file selected, it returns just the file name. When
there are multiple files selected, would a string containing the file
names, each surrounded by quotes and separated by semi-colons work?
e.g. test.txt;other.txt
There's a small problem with that too, because we would need a way to
handle file names that contained quote marks, which is possible on Mac
and Linux, but not on Windows.
But it really depends what use cases we need to address. Do authors
ever actually obtain the file name using JavaScript for anything? If
so, what for? With multiple file selection, is it likely they would
want to inspect each individual file name for anything, in which case,
should we find a way to make it easier to obtain individual file names?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
João Eiras wrote: I'd suggest for HTMLInputElement to have a .files or .paths property which would be an array of all the files choosen, names only. Whether or not it's worth doing that really depends what use cases we're trying to address. The initial post in this thread was just about defining what .value returns for file controls, which needs to be defined anyway and is what this thread should really focus on. I don't think we should jump to the conclusion that we really need to provide an array of individual file names without defining why that's even useful for authors, especially when doing so doesn't actually address the original problem that was raised. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Sandboxing to accommodate user generated content.
inside a data tag. If a developer forgot to escape the markup at all, then a user could enter /datascript.../script and do anything they wanted. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] [WF2] |min| and |max| number of selected |option|s
Christoph Päper wrote: Dear WHAT WG When using input type=checkbox or select multiple one somtimes wants to limit the number of selected check boxes or options. Could you provide some examples of some sites that need to apply such limits, and show how people are currently achieving this? Are there sites that use JavaScript to achieve this now, perhaps by listening for click events on the checkboxes, counting how many are checked and then preventing too many being checked. Or are there sites that count how many are checked onsubmit to ensure there aren't too few or too many? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Proposal: target=_tab
Simon Pieters wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. I don't believe it should be up to the document author to distinguish between a page opened up in a new window or new tab, since that is entirely a browser interface issue. Since several browsers already treat _blank in that way anyway, introducing a new keyword doesn't seem particularly useful. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width= height=
Martin Atkins wrote: Lachlan Hunt wrote: Martin Atkins wrote: Could this be said about size as well? link type=image/png media=all and (max-width:16px and max-height:16px) No, because the media queries are related to the actual tech specs of the device, not the image. I'm fairly sure there are no 16x16px screens in use, at least not for the web. To get appropriate behaviour for what you're suggesting here would require redefining and special casing media queries. When I shrink my browser window down so that its viewport is 16x16px (assuming that it'd let me do such a thing) it's quite happy to apply a stylesheet with the above media query. It seems, therefore, that the width and height constraints relate to the rendering viewport and not to the device. Yes, I meant device and viewport above. But even if you want to apply this to a special icon viewport, it still wouldn't work as you expect, because what we need is something that describes the properties of the image, not the properties of viewport it's being rendered in. Given a UA that can display any icon size up to, e.g., 128px square, the above media query wouldn't match. But what if the author only provided icons up to 64x64px, then no media query would match and no icon would be used. However, for this use case, the UA would need to pick the highest quality image that is suitable for the environment. You couldn't eve get away with using min-width/height here, because UAs generally stretch and scew icons to fit the necessary size, and say a 60x60 icon provided, and specified as: all and (min-width:60px) and (min-height:60px) Then the iPhone, for example, wouldn't pick it because it needs 59x60. Where there isn't a perfect size available, the UA needs to be able to pick one that is slightly smaller or larger and stretch it to fit. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width= height=
Charles Iliya Krempeaux wrote: link rel=enclosure type=image/xxx width=640 height=480 compressioning=lossy coloring=truecolor href=A.xxx link rel=enclosure type=image/xxx width=1280 height=960 compressioning=lossy coloring=truecolor href=A.xxx link rel=enclosure type=image/xxx width=2560 height=1920 compressioning=lossy coloring=truecolor href=A.xxx ... could become... link rel=enclosure type=image/xxx metadata=size:640x480, 1280x960, 2560x1920; compressioning:lossy; coloring:truecolor; href=A.xxx For color, you are reinventing Media Queries. For compression, you are basically reinventing q values for MIME types. link type=image/png;q=1.0 media=all and (min-color:8) link type=image/jpeg;q=0.8 media=all and (min-color:8) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width= height=
Martin Atkins wrote: Lachlan Hunt wrote: For color, you are reinventing Media Queries. For compression, you are basically reinventing q values for MIME types. link type=image/png;q=1.0 media=all and (min-color:8) link type=image/jpeg;q=0.8 media=all and (min-color:8) Could this be said about size as well? link type=image/png media=all and (max-width:16px and max-height:16px) No, because the media queries are related to the actual tech specs of the device, not the image. I'm fairly sure there are no 16x16px screens in use, at least not for the web. To get appropriate behaviour for what you're suggesting here would require redefining and special casing media queries. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] HTML semantics and file system
Samuel Santos wrote: When writing technical HTML documents, I often feel a need for an element to represent a path or a file in the file system. But I couldn't find any semantically correct element to do this. I usually use em class=filesystemC:\foo\bar/em but it just feels wrong... Is it worthy to have another HTML element like filesystem (I'm not sure if this is the better name for the element) to represent a path (e.g. C:\foo\bar) or a file name (e.g. README.txt)? The spec states (emphasis added): The code element represents a fragment of computer code. This could be an XML element name, a *filename*, a computer program, or any other string that a computer would recognise. http://www.whatwg.org/specs/web-apps/current-work/#the-code -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Duplicate Entity Reference Listed in Table of Entities
Hi, The spec currently lists the entity not; twice in the table of entities, as shown in this extract: ... nopf; U+1D55F not; U+000AC notU+000AC notin; U+02209 ... -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Expanding datetime
Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? ...The Y10K problem can also be pushed back by this, but is of only theoretical importance. There are still 7992 years before we need to have a Y10K solution implemented. Thus we can safely leave it to to future generations to solve. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Expanding datetime
Ernest Cline wrote: -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? No, I was just trying to emphasise the use cases that some of the datetime features have been included for. I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Please describe the authoring use cases that you are trying to solve and explain how and why authors or end users would benefit from having such dates marked up in a machine readable way, and why would it be in the interest of browser vendors to implement this feature? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
