Re: [whatwg] FYI: HTML usage data from Disqus websites
I'd be interested to see statistics on doctypes and character encodings, which weren't really present in the webstats data. What percentage of pages have a doctype, and of those that do, which doctype are they using? What percentage of pages specify a character encoding, and of those that do, which methods do they use? And which encodings do they specify? How many pages use plugins and which plugins are in use would be interesting too. Thanks. On 19 January 2011 10:59, Anton Kovalyov an...@disqus.com wrote: Hello, I work as a front-end engineer at Disqus. We are pretty popular commenting widget installed on around 500k websites throughout the world and visited by 300mln+ unique visitors per month. I am working on a project to gather some statistical data from the pages where our code is running to help us with some performance tuning. However, I want to use the opportunity and ask if this group is interested in some specific reports (like http://code.google.com/webstats/index.html). If you have some stats you'd like to see, let me know (by replying to this thread) and I will try to make it happen. Of course, the data will be completely anonymous and it has to be related to WHATWG's main focus. Results will be published probably by me on behalf of the company. Thanks, -- Anton Kovalyov Front-end Engineer, Disqus
Re: [whatwg] New method for obtaining a CSS property
On 1/27/2011 3:59 PM, Tab Atkins Jr. wrote: On Wed, Jan 26, 2011 at 10:23 PM, Brett Zamirbret...@yahoo.com wrote: For example, we want the designer guy to be able to freely change the colors in the stylesheet for indicating say a successful transition (green), an error (red), or waiting (yellow) for an Ajax request. The JavaScript girl does not want to have to change her code every time the designer has a new whim about making the error color a darker or lighter red, and the designer is afraid of getting balled out for altering her code improperly. So the JavaScript girl queries the .error class for the background-color property to get whatever the current error color is and then indicates to an animation script that darkred should be the final background color of the button after the transition. The retrieval might look something like: document.getCSSPropertyValue(.error, background-color); // 'darkred' While the JavaScript would choose the intermediate RGB steps to get there in the fashion desired by the developer. Yes, there are CSS transitions, or maybe SVG, but this is for cases where you want control tied to JavaScript. Or, for canvas specifically. You draw an animated Hello and want the designer to be able to choose the fill color. You want to be able to query the stylesheet easily to get the styling info. Given a selector, multiple declaration blocks could match, and within a single declaration block, multiple copies of the property can match. You could get any number of values back from a call like that, and there's no guarantee that the value you get is worth anything, because a property from some other declaration block with a different selector could be winning instead. I was thinking of it grabbing the winning property for the whole document, i.e., the one which would be applicable without knowing more contextual information. So, if the selector specified were .error, it wouldn't get div.error, but it could be defined for example to get the last .error and property (or perhaps giving precedence to !important). Whatever the rules, it would be the team's responsibility to ensure it was unique enough to provide the right value (as it is within CSS itself via cascading). It seems that your problem is that you want a way to declare a certain value to be reused in both CSS and javascript, so that you can change it in either realm without having to care about it in the other. This can be solved cleanly and easily with CSS Variables. The CSS Working Group has tried several times to agree on how such a thing should work, so far without success, but Chrome is trying again now. Check out my blog post on the subject: http://www.xanthir.com/blog/b49w0 I was only proposing a read-only system, but CSS Variables as you describe is indeed an excellent and attractively comprehensive and clean solution (and also address canvas requirements more smoothly, since variables could be defined with values which did not even map to a real CSS property, such as shadow color, as long as variables were made available to JavaScript whether or not they were actually used in the CSS). Still, also having the ability to easily get the value which wins out would have the one advantage of working without needing to change existing code to use variables. thanks, Brett
Re: [whatwg] New method for obtaining a CSS property
On 1/27/11 1:23 AM, Brett Zamir wrote: I'll give a more concrete example, but I did state the problem: separation of concerns, and the data I want, getting a CSS property for a given selector. selectors don't have properties. Elements have properties, and declarations have properties. selectors are a mechanism for tying rulesets to declarations. For example, we want the designer guy to be able to freely change the colors in the stylesheet for indicating say a successful transition (green), an error (red), or waiting (yellow) for an Ajax request. The JavaScript girl does not want to have to change her code every time the designer has a new whim about making the error color a darker or lighter red, and the designer is afraid of getting balled out for altering her code improperly. So the JavaScript girl queries the .error class for the background-color property to get whatever the current error color is and then indicates to an animation script that darkred should be the final background color of the button after the transition. The retrieval might look something like: document.getCSSPropertyValue(.error, background-color); // 'darkred' You can do that right now using getComputedStyle, with a bit more code, right? Or, for canvas specifically. You draw an animated Hello and want the designer to be able to choose the fill color. You want to be able to query the stylesheet easily to get the styling info. Or just set a class on your canvas and let styles apply to it as normal? -Boris
Re: [whatwg] New method for obtaining a CSS property
On 1/27/11 4:48 AM, Brett Zamir wrote: I was thinking of it grabbing the winning property for the whole document, i.e., the one which would be applicable without knowing more contextual information. So, if the selector specified were .error, it wouldn't get div.error That's pretty difficult to define, actually. Should it get .error.error? Whatever the rules, it would be the team's responsibility to ensure it was unique enough to provide the right value (as it is within CSS itself via cascading). Why is just asking for computed style, and getting correct answers that include the results of the cascade, not the right solution here? -Boris
Re: [whatwg] New method for obtaining a CSS property
Boris Zbarsky bzbar...@mit.edu wrote: On 1/27/11 4:48 AM, Brett Zamir wrote: I was thinking of it grabbing the winning property for the whole document, i.e., the one which would be applicable without knowing more contextual information. So, if the selector specified were .error, it wouldn't get div.error That's pretty difficult to define, actually. Should it get .error.error? Whatever the rules, it would be the team's responsibility to ensure it was unique enough to provide the right value (as it is within CSS itself via cascading). Why is just asking for computed style, and getting correct answers that include the results of the cascade, not the right solution here? -Boris Without context you can't get the cascading or winning values for css attributes. You could create a whole pseudo document to get this, but it is needlessly complex. You say you would want .error to not get matched by div.error, but in a real document the order of the styles and the weight of them (id's over classes, !important rules, etc) dictate the final style attributes. Thanks Ash http://www.ashleysheridan.co.uk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
[whatwg] Media elements statistics
Hi, I'd like the raise this thread again: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027929.html (I wasn't on the list at that point, so starting a new thread here and cc'ing a couple of folks from it...) I work on the media stack in Chromium and we'd like to implement something pretty similar. So I'm looking for comments... The original suggestion for the video element looks good: [Video Element] // Frames decoded and available for playback. unsigned long decodedFrames; // Frames dropped during playback for performance reasons. unsigned long droppedFrames; But for the media element I'd like to propose raw bytes instead of a rate as this allows the developer to construct their own rates (if needed) based on whatever window they want. It would also be useful to separate audio from video. A suggestion might be: [Media Element] unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Though this seems a little strange to have these specifically on the media element as they reference particular media types. Another idea would be to move these to the video element and also add audioBytesDecoded to the audio element. Another open question: what are sensible values if the information is not available. Zero seems wrong. Thoughts? Cheers! Steve
Re: [whatwg] Media elements statistics
Hi Steve et al, I'm working on a similar feature for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 Though we're implementing this more as a way of measuring the performance of our decoding and rendering pipeline, rather than providing playback/decode-rate stats. unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Out of curiosity, why do you want this feature? What does it give you that @buffered and @currentTime does not? Raw bytes reasonable to me, the feedback on the FOMS list regarding playback statistics showed webdevs liked that idea. How would you handle frames dropped by the decoder in order to prevent it falling behind? Would you count their bytes as decoded? Another open question: what are sensible values if the information is not available. Zero seems wrong. Return Number.NaN? Or provide some kind of ability to query whether there is audio and video? Regards, Chris P. On 28/01/2011 12:22 p.m., Steve Lacey wrote: Hi, I'd like the raise this thread again: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027929.html (I wasn't on the list at that point, so starting a new thread here and cc'ing a couple of folks from it...) I work on the media stack in Chromium and we'd like to implement something pretty similar. So I'm looking for comments... The original suggestion for the video element looks good: [Video Element] // Frames decoded and available for playback. unsigned long decodedFrames; // Frames dropped during playback for performance reasons. unsigned long droppedFrames; But for the media element I'd like to propose raw bytes instead of a rate as this allows the developer to construct their own rates (if needed) based on whatever window they want. It would also be useful to separate audio from video. A suggestion might be: [Media Element] unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Though this seems a little strange to have these specifically on the media element as they reference particular media types. Another idea would be to move these to the video element and also add audioBytesDecoded to the audio element. Another open question: what are sensible values if the information is not available. Zero seems wrong. Thoughts? Cheers! Steve
Re: [whatwg] Media elements statistics
On Thu, Jan 27, 2011 at 3:53 PM, Chris Pearce ch...@pearce.org.nz wrote: Hi Steve et al, I'm working on a similar feature for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 Though we're implementing this more as a way of measuring the performance of our decoding and rendering pipeline, rather than providing playback/decode-rate stats. unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Out of curiosity, why do you want this feature? What does it give you that @buffered and @currentTime does not? Being able to determine the bitrate that's currently being decoded has been a request from devs (for similar reasons that devs on the FOMS list have I expect). Raw data seems generally useful. Raw bytes reasonable to me, the feedback on the FOMS list regarding playback statistics showed webdevs liked that idea. How would you handle frames dropped by the decoder in order to prevent it falling behind? Would you count their bytes as decoded? Right now I include the frames dropped in the decoded count. It's kinda orthogonal to frames decoded/dropped as one (bytesdecoded) gives the performance for decoding and the frame counts give performance of presentation. Another open question: what are sensible values if the information is not available. Zero seems wrong. Return Number.NaN? Or provide some kind of ability to query whether there is audio and video? Thanks! Regards, Chris P. On 28/01/2011 12:22 p.m., Steve Lacey wrote: Hi, I'd like the raise this thread again: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027929.html (I wasn't on the list at that point, so starting a new thread here and cc'ing a couple of folks from it...) I work on the media stack in Chromium and we'd like to implement something pretty similar. So I'm looking for comments... The original suggestion for the video element looks good: [Video Element] // Frames decoded and available for playback. unsigned long decodedFrames; // Frames dropped during playback for performance reasons. unsigned long droppedFrames; But for the media element I'd like to propose raw bytes instead of a rate as this allows the developer to construct their own rates (if needed) based on whatever window they want. It would also be useful to separate audio from video. A suggestion might be: [Media Element] unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Though this seems a little strange to have these specifically on the media element as they reference particular media types. Another idea would be to move these to the video element and also add audioBytesDecoded to the audio element. Another open question: what are sensible values if the information is not available. Zero seems wrong. Thoughts? Cheers! Steve
Re: [whatwg] Media elements statistics
On Thu, Jan 27, 2011 at 3:38 PM, Chris Double chris.dou...@double.co.nz wrote: On Fri, Jan 28, 2011 at 12:22 PM, Steve Lacey s...@chromium.org wrote: But for the media element I'd like to propose raw bytes instead of a rate as this allows the developer to construct their own rates (if needed) based on whatever window they want. It would also be useful to separate audio from video. A suggestion might be: Raw bytes sounds good. unsigned long audioBytesDecoded; unsigned long videoBytesDecoded; Though this seems a little strange to have these specifically on the media element as they reference particular media types. Another idea would be to move these to the video element and also add audioBytesDecoded to the audio element. Moving them to the video and audio element would mean you can't get the audioBytesDecoded on a video element which is what I'm assuming you want by having the two values. Yeah - I'd also add audioBytesDecoded to the audio element, which is an unpleasant dupe. Note that the Mozilla implementation I proposed has had a counter proposal by another mozilla developer and is being developed further. See: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 Thanks. Taking a further look at that. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.
A CORS based answer to this would work for the folks that have expressed an interest in this capability to me. cc'ing some other appcache implementors too... any thoughts? On Wed, Jan 26, 2011 at 12:28 PM, Michael Nordman micha...@google.com wrote: I was alluding to a simple robots.txt like solution with the static 'allow' file, but it seems like CORS could work too, it is more burdensome to setup due to the additional HTTP headers. GET /some-resource Origin: https://acme.com HTTP/1.x 200 OK Access-Control-Allow-Origin: * | https://acme.com Unless the the origin is allowed, the resource will not be added to the cache and the update will fail. .. On Wed, Jan 26, 2011 at 12:50 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 25 Jan 2011 23:37:55 +0100, Michael Nordman micha...@google.com wrote: Would the public-webapps list be better for discussing appcache feature requests? It's not a feature drafted in any of the WebApps WG specifications. If you want to discuss at the W3C the appropriate place would be the HTML WG. Also, http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F might be interesting. (Though you are probably aware of it.) This could be as simple as the presence of an 'applicationcaching_allowed' file at the top level. An https manifest update that wants to retrieve resources from another https origin would first have to fetch the 'allow' file and see an expected response, and if it doesn't see a good response, those xorigin entries would be skipped (matching today's behavior). The request... GET /applicationcaching_allowed Referer: manifestUrl of the cache trying to include resources from this host The expected response headers... HTTP/1.x 200 OK Content-Type: text/plain The expected response body... Allowed:* So far we have avoided this type of design as it is rather brittle. Maybe CORS can be used? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.
On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman micha...@google.com wrote: A CORS based answer to this would work for the folks that have expressed an interest in this capability to me. cc'ing some other appcache implementors too... any thoughts? CORS has the semantics of you're allowed to make these types of requests to this resource, and you're allowed to read the response from such requests. This is very different from what is being requested here as I understand it? So either we'd need to add more headers to CORS, or come up with some other header-based solution I think. / Jonas
Re: [whatwg] New method for obtaining a CSS property
On 1/28/2011 2:19 AM, Boris Zbarsky wrote: On 1/27/11 1:23 AM, Brett Zamir wrote: I'll give a more concrete example, but I did state the problem: separation of concerns, and the data I want, getting a CSS property for a given selector. selectors don't have properties. Elements have properties, and declarations have properties. selectors are a mechanism for tying rulesets to declarations. My point is that a selector can be tied to a property through the ruleset. I recognize there may be more than one declaration even with the same property being associated with the same selector, but I'm suggesting to define some rules for selecting the most logical match. Even if it cannot match the same behavior for contextual style determination (which as Ashley pointed out follows its own cascading rules which do not apply here), interpreting it predictably (e.g., either the very first or very last exact match if there are other exact duplicate selector references) and as literally as possible (e.g., .error would not match .error.error nor div.error) should address the use cases I am mentioning. For example, we want the designer guy to be able to freely change the colors in the stylesheet for indicating say a successful transition (green), an error (red), or waiting (yellow) for an Ajax request. The JavaScript girl does not want to have to change her code every time the designer has a new whim about making the error color a darker or lighter red, and the designer is afraid of getting balled out for altering her code improperly. So the JavaScript girl queries the .error class for the background-color property to get whatever the current error color is and then indicates to an animation script that darkred should be the final background color of the button after the transition. The retrieval might look something like: document.getCSSPropertyValue(.error, background-color); // 'darkred' You can do that right now using getComputedStyle, with a bit more code, right? Yes, or by iterating through document.stylesheets. But as Ashley pointed out, it is needlessly complex to create one's own pseudo document for this purpose, and I think it should be a simple operation to be able to do something as fundamental as following best practices. But the CSS Variables Tab suggested would work pretty well to meet this need as well, though it would require altering existing CSS to be parameterized. Or, for canvas specifically. You draw an animated Hello and want the designer to be able to choose the fill color. You want to be able to query the stylesheet easily to get the styling info. Or just set a class on your canvas and let styles apply to it as normal? Maybe you are thinking of SVG here? One can't do something like this with canvas: canvas style=fillStyle:rgb(200,0,0)/canvas ..and even if one could, it would not be targeted to the specific shapes needing styling. thanks, Brett
Re: [whatwg] New method for obtaining a CSS property
On 1/28/2011 2:22 AM, Boris Zbarsky wrote: On 1/27/11 4:48 AM, Brett Zamir wrote: I was thinking of it grabbing the winning property for the whole document, i.e., the one which would be applicable without knowing more contextual information. So, if the selector specified were .error, it wouldn't get div.error That's pretty difficult to define, actually. Should it get .error.error? As mentioned in my other response just now, no, I don't think it should. The idea is to be as literal as possible, following a predictable path (e.g., the very first or maybe very last reference). It couldn't and wouldn't need to follow CSS cascading behavior, since the purpose here is different. It would generally be expected that there would only be one match since the designer and developer would coordinate to find a unique match. As with regular contextual CSS, one needs to be careful not to overwrite one's own rules, but this use case is treating selector-property associations as (read-only) variables rather than contextually resolved style rules. Still, it could also be made to follow cascading behavior (e.g., !important getting higher precedence). As long as it was predictable, the point is for there to be a clear way to figure it out. Whatever the rules, it would be the team's responsibility to ensure it was unique enough to provide the right value (as it is within CSS itself via cascading). Why is just asking for computed style, and getting correct answers that include the results of the cascade, not the right solution here? Sure, one could pick an arbitrary element, and hope it didn't have its own style attribute, or again, make a pseudo document, but this does not seem as satisfying as just querying the stylesheets, as one can do--but only by an extra utility function--in iterating through document.stylesheets. Best practice should not require hacks, in my opinion. One should be able to just tell people, if you want to grab a style property value defined in a stylesheet dynamically in JavaScript, use this simple method to do so. thanks, Brett
Re: [whatwg] New method for obtaining a CSS property
On Wed, Jan 26, 2011 at 10:23 PM, Brett Zamir bret...@yahoo.com wrote:
I'll give a more concrete example, but I did state the problem: separation
of concerns, and the data I want, getting a CSS property for a given
selector.
For example, we want the designer guy to be able to freely change the
colors in the stylesheet for indicating say a successful transition (green),
an error (red), or waiting (yellow) for an Ajax request. The JavaScript girl
does not want to have to change her code every time the designer has a new
whim about making the error color a darker or lighter red, and the designer
is afraid of getting balled out for altering her code improperly. So the
JavaScript girl queries the .error class for the background-color
property to get whatever the current error color is and then indicates to an
animation script that darkred should be the final background color of the
button after the transition. The retrieval might look something like:
document.getCSSPropertyValue(.error, background-color); // 'darkred'
While the JavaScript would choose the intermediate RGB steps to get there
in the fashion desired by the developer.
Yes, there are CSS transitions, or maybe SVG, but this is for cases where
you want control tied to JavaScript.
It sounds like all you want to do is:
function getColor(className) {
var dummy = document.createElement('div');
dummy.className = className;
document.body.appendChild(dummy);
var color = dummy.style.backgroundColor;
document.body.removeChild(dummy);
return color;
}
- Ryosuke
Re: [whatwg] New method for obtaining a CSS property
Boris Zbarsky bzbar...@mit.edu wrote: On 1/28/11 1:22 AM, Brett Zamir wrote: My point is that a selector can be tied to a property through the ruleset. No, not really. Something that _matches_ selectors an be tied to a property via seeing which selectors it matches and then considering the resulting declaration lists I recognize there may be more than one declaration even with the same property being associated with the same selector, but I'm suggesting to define some rules for selecting the most logical match. So rules for matching selectors to selectors, right? Defining these could really get pretty complex, unless you're suggesting that it just be a string compare of the serializations or something. You can do that right now using getComputedStyle, with a bit more code, right? Yes, or by iterating through document.stylesheets. Um... why would you do that? But as Ashley pointed out, it is needlessly complex to create one's own pseudo document Why would you need to create a pseudo document? for this purpose, and I think it should be a simple operation to be able to do something as fundamental as following best practices. Ideally, yes, but setting styles directly from script (as opposed to setting classes that are then styled by the stylesheet) is not exactly best practices, unless we're looking at different best practices lists. Or, for canvas specifically. You draw an animated Hello and want the designer to be able to choose the fill color. You want to be able to query the stylesheet easily to get the styling info. Or just set a class on your canvas and let styles apply to it as normal? Maybe you are thinking of SVG here? No, I'm not. Per the canvas spec, if I read it right, doing this: myCanvas.className = somethingStyled; myCanvas.fillStyle = currentColor; should set the fill style to the computed value of color on myCanvas (and in particular, to whatever that computed value is given the class somethingStyled). As it happens, Gecko doesn't implement this yet, but the spec says to do it. See http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-canvas paragraph starting Whenever the CSS value currentColor. ..and even if one could, it would not be targeted to the specific shapes needing styling. Canvas isn't retained-mode. So you set your fill style, then draw the shapes that need to have that style. If you want a different style for different shapes, you set the new fill style and draw those shapes. There's no magic targeting involved... -Boris Ross, I think you're getting caught up in the everything has its own class thing with css. I've seen people look create code like this before just because they wanted to style the list items: ul class=some_list li class=some_item li class=some_item li class=some_item /ul Every list element has the same class, just seemed as if nobody knew that ul.some_list some_item matched the li tags. With your suggested behaviours, things like these selector are ignored. What would you have happen where you needed to get a property of the .special class in the following selectors: p span.special body.page1 p.special body.page2 p.special span.special With no document context, anything you get would be meaningless. Thanks Ash http://www.ashleysheridan.co.uk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
