Re: [whatwg] How to handle multitrack media resources in HTML
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 audio descriptions, sign language
video, and dubbed audio tracks.
We require an API that can expose such extra tracks to the user and to
JavaScript. This should be independent of whether the tracks are
actually inside the media resource or are given as separate resources,
I think there's a big difference between multiple tracks inside one
resource and multiple tracks spread amongst multiple resources: in the
former case, one would need a single set of network state APIs (load
algorithm, ready state, network state, dimensions, buffering state, etc),
whereas in the second case we'd need N set of these APIs, one for each
media resource.
Given that the current mechanism for exposing the load state of a media
resource is a media element (video, audio), I think it makes sense to
reuse these elements for loading each media resource even in a multitrack
scenario. Thus I do not necessarily agree that exposing extra tracks
should be done in a way that as independent of whether the tracks are
in-band or out-of-band.
but should be linked to the main media resource through markup.
What is a main media resource?
e.g. consider youtubedoubler.com; what is the main resource?
Or similarly, when watching the director's commentary track on a movie, is
the commentary the main track, or the movie?
I am bringing this up now because solutions may have an influence on the
inner workings of TimedTrack and the track element, so before we have
any implementations of track, we should be very certain that we are
happy with the way in which it works - in particular that track
continues to stay an empty element.
I don't really see why this would be related to text tracks. Those have
their own status framework, and interact directly with a media element.
Looking again at the youtubedoubler.com example, one could envisage both
sides having text tracks. They wouldn't be joint tracks.
On Mon, 14 Feb 2011, Jeroen Wijering wrote:
In terms of solutions, I lean much towards the manifest approach. The
other approaches are options that each add more elements to HTML5,
which:
* Won't work for situations outside of HTML5.
* Postpone, and perhaps clash with, the addition of manifests.
Manifests, and indeed any solution that relies on a single media element,
would make it very difficult to render multiple video tracks independently
(e.g. side by side vs picture-in-picture). That's not to say that
manifests shouldn't work, but I think we'd need another solution as well.
*) The CSS styling issue can be fixed by making a conceptual change to
CSS and text tracks. Instead of styling text tracks, a single text
rendering area for each video element can be exposed and styled. Any
text tracks that are enabled push data in it, which is automatically
styled according to the video.textStyle/etc rules.
This wouldn't work well with positioned captions.
*) Discoverability is indeed an issue, but this can be fixed by defining
a common track API for signalling and enabling/disabling tracks:
{{{
interface Track {
readonly attribute DOMString kind;
readonly attribute DOMString label;
readonly attribute DOMString language;
const unsigned short OFF = 0;
const unsigned short HIDDEN = 1;
const unsigned short SHOWING = 2;
attribute unsigned short mode;
};
interface HTMLMediaElement : HTMLElement {
[...]
readonly attribute Track[] tracks;
};
}}}
There's a big difference between text tracks, audio tracks, and video
tracks. While it makes sense, for instance, to have text tracks enabled
but not showing, it makes no sense to do that with audio tracks.
Similarly, video tracks need their own display area, but text tracks need
a video track's display area. A single video area can display one video
(multiple overlapping videos being achieved by multiple playback areas),
but multiple audio and text tracks can be mixed together without any
difficulty (mixing in one audio channel, or positioning over one video
display area, respectively).
So I'm not sure a single tracks API makes sense.
On Wed, 16 Feb 2011, Eric Winkelman wrote:
We're working with multitrack MPEG transport streams, and have an
implementation of the TimedTrack interface integrating with in-band
metadata tracks. Our prototype uses the Metadata Cues to synchronize a
JavaScript application with a video stream using the stream's embedded
EISS signaling. This approach is working very well so far.
The biggest issue we've faced is that there isn't an obvious way to tell
the browser application what type of information is contained within the
metadata track/cues. The Cues can contain
Re: [whatwg] Media elements statistics
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: http://learn.iis.net/page.aspx/582/advanced-logging-for-iis-70---client-logging/ Apart from the statistics that are not currently available from the HTML5 player, there are stats that are already available, such as currentSrc, currentTime, and all the events which can be turned into hooks for measurement. Yes, the network and ready states are very useful to determine if clients are stalling for buffering etc. I think the page now has a lot of analysis of currently used stats - probably a sufficient amount. All the video publishing sites likely just use a subpart of the ones that Adobe Flash exposes in their analytics. Especially all the separate A/V bytecounts are overkill IMO. One useful metric I didn't list for JW Player but is very nice is Flash's isLive property. Kind regards, Jeroen On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson wats...@netflix.com wrote: All, I added some material to the wiki page based on our experience here at Netflix and based on the metrics defined in MPEG DASH for adaptive streaming. I'd love to here what people think. Statistics about presentation/rendering seem to be covered, but what should also be considered are network performance statistics, which become increasingly difficult to collect from the server when sessions are making use of multiple servers, possibly across multiple CDNs. Another aspect important for performance management is error reporting. Some thoughts on that on the page. ...Mark On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote: On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce ch...@pearce.org.nz wrote: On 1/04/2011 12:22 p.m., Steve Lacey wrote: Chris - in the mozilla stats, I agree on the need for a frame count of frames that actually make it the the screen, but am interested in why we need both presented and painted? Wouldn't just a simple 'presented' (i.e. presented to the user) suffice? We distinguish between painted and presented so we have a measure of the latency in our rendering pipeline. It's more for our benefit as browser developers than for web developers. Yeah, just to be clear, we don't necessarily think that everything in our stats API should be standardized. We should wait and see what authors actually use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
[whatwg] PeerConnection constructor: Init string format
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.
TYPE relay.example.net:3478
Indicates a specific host and port for the server; the user agent will
look up the IP address in DNS.
TYPE example.net
Indicates a specific domain for the server; the user agent will look up
the IP address and port in DNS.
The TYPE is one of:
STUN
Indicates a STUN server
STUNS
Indicates a STUN server that is to be contacted using a TLS session.
TURN
Indicates a TURN server
TURNS
Indicates a TURN server that is to be contacted using a TLS session.
---
I believe this is insufficient, for a number of reasons:
- For future extensibility, new forms of init data needs to be passed
without invalidating old implementations. This indicates that a
serialized JSON object with a few keys of defined meaning is a better
basic structure than a format string with no format identifier.
- For use with STUN and TURN, we need to support the case where we need
a STUN server and a TURN server, and they're different.
- The method of DNS lookup is not specified. In particular, it is not
specified whether SRV records are looked up or not.
- We have no evaluation that shows that we'll never need the unencrypted
TCP version of STUN or TURN, or that we need to support the encrypted
STUN version. We should either support all formats that the spec can
generate, or we should get a reasonable survey of implementors on what
they think is needed.
My alternate proposal:
--
The initialization string looks like this:
{
“stun_service”: { “host”: “stun.example.com”,
“service”: “stun”,
“protocol”: “udp”
},
“turn_service”: { “host”: “turn.example.com” }
}
The STUN server may either be an IP address:port literal, or be a domain
name. If it is a domain name, the procedure in section 9 of RFC 5389
(SRV record lookup, with fallback to port 3478 (STUN) or 5349 (STUN over
TLS)) is used to establish the IP address and port to use for STUN and TURN.
If “service” and “protocol” are omitted, they are assumed to be “stun”
and “udp” for stun_service, and “turn” and “udp” for turn_service.
For TURN, the procedure is defined in RFC 5766 section 6.1. The
procedure of RFC 5928 (using S-NAPTR applications) is not used.
Re: [whatwg] Styling details
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 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 Yup, looks good. 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 ▷.
Re: [whatwg] Styling details
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 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 Yup, looks good. FWIW I don't think we need cross-browser agreement here. I strongly agree, because agreement on icons would work against the idea of competition and variation between platforms and browsers as well as the idea of platform-wide conventions that users may be accustomed to. On the technical side, the characters proposed are not visually obvious - being regular triangles, they are subject to variation on how they are seen as pointing somewhere. U+25C2, especially in isolation, might be seen as pointing to northeast... Besides, when I first looked at the quoted text, I was using an Android, and all the triangles appeared as replaced by small rectangles. So their font coverage isn't particularly good. 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 ▷. A key issue in making details work for users, and therefore motivating authors into using it, is how to make it as obvious as possible to understand that there is some detailed information available, though currently hidden, and that there is an obvious way to get to it. This is quite a challenge - but to visual designers and usability experts and implementors, not to people who write general specifications. Hopefully, _several_ essentially different experimental (or other) implementations will emerge, will be discussed and tested, and some successful ideas will prevail. -- Yucca, http://www.cs.tut.fi/~jkorpela/
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] Geolocation - Browser usability issues with regards to asking user permission
Biju wrote: What I want from browser vendors is make navigator.geolocation.getCurrentPosition and navigator.geolocation.watchPosition ONLY callable from a CLICK event. I thought we all learned lesson from window.open popups window.open is still entirely underspecified in standards when it comes to its behavior in trusted vs. non-trusted click event invocation. The first thing somebody would need to is document how window.open works according to different modes of invocation. Then at least we would have a model to be able to discuss for other similar scenarios. What you're then suggesting is that we allow *trusted* click events (according to the DOM Level 3 Events definition) to trigger a non-blocking dialog to enable geolocation in the same way as window.open only opens a popup window if it has been called from a trusted user-initiated click event. That seems logical to me and it's something that we attempted to define in a blue-sky proposal elsewhere: http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom-events. The same model could potentially be applied to geolocation and other upcoming Web APIs. The ability for a user to click something and receive a response that fits their work flow, instead of an async bar that the OP suggested users are frequently missing seems like something we should look in to more. Some interaction that's a little bit like the file picker interaction, but with a non-modal output notification. - Rich
Re: [whatwg] Styling details
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. 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. 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. ~TJ
Re: [whatwg] PeerConnection constructor: Init string format
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”: “stun”,
“protocol”: “udp”
},
“turn_service”: { “host”: “turn.example.com” }
}
FWIW, I thought the block-of-text configuration string was peculiar and
unlike anything else in the platform. I agree that using a configuration
object (of some kind) makes more sense.
--
Glenn Maynard
Re: [whatwg] Styling details
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 premature to consider such things. We don’t know what are the feasible or optimal renderings of details elements. Actually, if you wish to make them widely understood and used, you _don’t_ want to encourage authors to suggest their idiosyncratic renderings. On the average, a web author, left alone, creates a much poorer user interface than a person designing a web browser – simply because the latter is some kind of a professional in such matters. If we use 'list-style-type', it seems reasonable to at least agree on a common list-style-type value. Why should we use list-style-type for something that clearly ain’t no list? -- Yucca, http://www.cs.tut.fi/~jkorpela/
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
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 should we use list-style-type for something that clearly ain’t no list? Because it appears that the disclosure triangle wants to have the same behavior that ::marker does. 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? Don't be misled by the name - all that list-style-type does is help construct the default value for 'content' on ::marker. It has nothing to do with things that are semantically lists, per se. 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”. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] How to handle multitrack media resources in HTML
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 (as well as playbackState, networkState, seekable, and buffered). I'm not sure what networkState in this context. playbackState, assuming you mean 'paused', is already exposed. Sorry, by playbackState, I meant readyState. And I was suggesting that, much in the same way that you've provided .buffered and .seekable properties which expose the intersection of the slaved media elements' corresponding ranges, that a readyState property could similarly reflect the readyState values of all the slaved media elements. In this case, the MediaController's hypothetical readyState wouldn't flip to HAVE_ENOUGH_DATA until all the constituent media element's ready states reached at least the same value. Of course, this would imply that the load events fired by a media element (e.g. loadedmetadata, canplaythrough) were also fired by the MediaController, and I would support this change as well. Again, this would be just a convenience for authors, as this information is already available in other forms and could be relatively easily calculated on-the-fly in scripts. But UAs are likely going to have do these calculations anyway to support things like autoplay, so adding explicit support for them in API form would not (imho) be unduly burdensome. -Jer Jer Noble jer.no...@apple.com
Re: [whatwg] Styling details
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. If that's overreaching, then I'm content to say that *I* want it to be fully author-stylable, but I believe Moz feels similarly (Tantek is working on making the form controls more author-stylable). Why should we use list-style-type for something that clearly ain’t no list? Because it appears that the disclosure triangle wants to have the same behavior that ::marker does. 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. However, the default visual behavior of details is suggested in the HTML spec. Don't be misled by the name - all that list-style-type does is help construct the default value for 'content' on ::marker. It has nothing to do with things that are semantically lists, per se. 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. ~TJ
Re: [whatwg] How to handle multitrack media resources in HTML
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 getting this information out-of-band we would, as you suggest, know how to deal with it. We would use multiple @kind=metadata tracks, with the correct handler associated with each track. In our case, however, this information is all coming in-band. There is information within the MPEG transport stream that identifies the types of metadata being carried. This lets the video player know, for example, that the stream has a particular track with application triggers, and another one with content advisories. To be consistent with the out-of-band tracks, we envision the player creating separate TimedTrack elements for each type of metadata, and adding the associated data as cues. But there isn't a clear way for the player to indicate the type of metadata it's putting into each of these TimedTrack cues. Which brings us to the mime types. I have an event handler on the video tag that fires when the player creates a new metadata track, and this handler tries to figure out what to do with the track. Without a type on the track, I have to set another handler on the track that fires when the player creates a cue, and tries to figure out what to do from the cue. As there is no type on the cue either, I have to examine the cue location/text to see if it contains metadata I'm able to handle. This all works, but it requires event handlers on tracks that may have no interest to the application. On the player side, it depends on the player tagging the metadata in a consistent ad-hoc way, as well as requiring the player to create separate metadata tracks. (We also considered starting the cue's text with a mime type, but this has the same basic issues.) This is an interesting problem. What is the way that the MPEG streams identify these various metadata streams? Is it a MIME type? Some other identifier? Is this identifier separate from the track's label, or is it the track's label? The streams contain a Program Map Table (PMT) which contains a list of tuples (program id (PID) and a standard numeric type) for the program's tracks. This is how the user agent knows about this metadata and what is contained in it. We're envisioning that the combination of transport, e.g. MPEG-2 TS, and PMT type would be used by the UA to select a MIME type. We're proposing that this MIME type would be the track's label. We think it would be better if there were a type attribute for the track to use instead of the label, but using the label would work. Thanks, Eric --- e.winkel...@cablelabs.com
[whatwg] Accept full CSS colors in the legacy color parsing algorithm
In the legacy color parsing algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value, steps 5 and 6 concern CSS color names - 'transparent' should raise an error, and color names should be respected. All other CSS color syntaxes, though, such as the rgba() function, are just passed through to the rest of the algorithm and appropriately mangled. This doesn't match Webkit's behavior. Instead of steps 5 and 6, we just try to parse it as a CSS color. If we succeed, we use that color. Otherwise, we chunk it into the legacy parsing algorithm and do what the spec says. So, for example, font color=rgba(255,0,0,.5)foo/font is actually displayed as partially-transparent red instead of dark green (following the algorithm mangles the string into #050). Could we change those two steps to just say If keyword is a valid CSS color value, then return the simple color corresponding to that value.? (I guess, to fully match Webkit, you need to change the definition of simple color to take alpha into account.) ~TJ
Re: [whatwg] Styling details
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. 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. 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”? 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 progress, which is what it really is. 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. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
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 names should be respected. All other CSS color syntaxes, though, such as the rgba() function, are just passed through to the rest of the algorithm and appropriately mangled. This doesn't match Webkit's behavior. But it does match other UAs Could we change those two steps to just say If keyword is a valid CSS color value, then return the simple color corresponding to that value.? (I guess, to fully match Webkit, you need to change the definition of simple color to take alpha into account.) Do you have web compat data here? I would much rather stick with color parsing as defined in HTML4 modulo the not a color name, treat it as a hex color even if it doesn't start with '#' quirk than replace the is it a color name? test with a does it parse as a CSS color? test. -Boris
Re: [whatwg] Styling details
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 progress, which is what it really is. 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. Sigh. I'm not going to respond to you if you're just blatantly trolling. ~TJ
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
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 concern CSS color names - 'transparent' should raise an error, and color names should be respected. All other CSS color syntaxes, though, such as the rgba() function, are just passed through to the rest of the algorithm and appropriately mangled. This doesn't match Webkit's behavior. But it does match other UAs I suspected it did; this just seemed like a half-useful difference. Could we change those two steps to just say If keyword is a valid CSS color value, then return the simple color corresponding to that value.? (I guess, to fully match Webkit, you need to change the definition of simple color to take alpha into account.) Do you have web compat data here? I would much rather stick with color parsing as defined in HTML4 modulo the not a color name, treat it as a hex color even if it doesn't start with '#' quirk than replace the is it a color name? test with a does it parse as a CSS color? test. I might agree with you here, now that I think about it more. It would make it easier for me to deploy my 4/8 hexit patch, since there *is* a small compat cost in the form of people doing font color=# and expecting it to be black. ~TJ
