On Thu, 10 Feb 2011, Silvia Pfeiffer wrote:
One particular issue that hasn't had much discussion here yet is the
issue of how to deal with multitrack media resources or media resources
that have associated synchronized audio and video resources. I'm
concretely referring to such things as
On Apr 7, 2011, at 8:11 AM, Silvia Pfeiffer wrote:
I've also just added a section with the stats that the Adobe Flash
player exposes.
Great. Perhaps Silverlight stats might be of use too - though they're fairly
similar:
Adding this to the public archive:
The current (April 8) version of section 9.4 says that the config string
for a PeerConnection object is this:
---
The allowed formats for this string are:
TYPE 203.0.113.2:3478
Indicates a specific IP address and port for the server.
On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote:
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
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
James Graham wrote:
On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote:
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan
Huntlachlan.h...@lachy.id.au wrote:
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
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
Biju wrote:
What I want from browser vendors is make
navigator.geolocation.getCurrentPosition
and navigator.geolocation.watchPosition ONLY callable from a CLICK event.
I thought we all learned lesson from window.open popups
window.open is still entirely underspecified in standards when it
On Fri, Apr 8, 2011 at 5:05 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
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.
On Fri, Apr 8, 2011 at 4:41 AM, Harald Alvestrand har...@alvestrand.nowrote:
My alternate proposal:
--
The initialization string looks like this:
{
“stun_service”: { “host”: “stun.example.com”,
“service”:
Lachlan Hunt wrote:
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.
It’s far too
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.
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?
Why
On Apr 7, 2011, at 11:54 PM, Ian Hickson wrote:
The distinction between a master media element and a master media
controller is, in my mind, mostly a distinction without a difference.
However, a welcome addition to the media controller would be convenience
APIs for the above properties
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
On Friday, April 08, 2011, Ian Hickson wrote:
On Thu, 17 Feb 2011, Eric Winkelman wrote:
MPEG transport streams, as used for commercial TV, will often contain
multiple types of metadata: content advisories, ad insertion
opportunities, interactive TV application triggers, etc. If we were
In the legacy color parsing algorithm
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value,
steps 5 and 6 concern CSS color names - 'transparent' should raise an
error, and color names should be respected. All other CSS color
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
On 4/8/11 1:54 PM, Tab Atkins Jr. wrote:
In the legacy color parsing algorithm
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value,
steps 5 and 6 concern CSS color names - 'transparent' should raise an
error, and color
On Fri, Apr 8, 2011 at 2:20 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
Tab Atkins Jr. wrote:
However, the default visual behavior
of details is suggested in the HTML spec.
You misspelled ”the current HTML(5) draft/sketch”. And I would not take it
as more than a suggestion in a work in
On Fri, Apr 8, 2011 at 2:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/8/11 1:54 PM, Tab Atkins Jr. wrote:
In the legacy color parsing algorithm
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value,
steps 5 and 6
20 matches
Mail list logo
