Re: [whatwg] Video playback quality metric
On Mon, 09 Feb 2009 22:13:09 +0100, Jeremy Doig jerem...@google.com wrote: Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well.Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? While I think this kind of thing might be useful, I would be careful about requiring any kind of detailed metrics like dropped frames or effective frame rate to be exposed via DOM, as getting this information reliably over different devices, platforms and media frameworks would be quite difficult. How about an event which the user agent can optionally fire to indicate that it cannot play at the requested rate due to processing/memory constraints (rather than network)? This would (I think) provide the same functionality but put less burden on implementors. There is already a placeholder for non-fatal errors in the spec, perhaps this could be included with that in some fashion? -- Philip Jägenstedt Opera Software
Re: [whatwg] [web-apps] Ability to treat transparent part of element transparent to events
On Tue, 11 Jan 2005, martijnw wrote: See: https://bugzilla.mozilla.org/show_bug.cgi?id=102695 - Treat some transparent elements as transparent to events I think that explains basically what I would like to have. Afaik, that's something that IE is already doing (at least I heard). Basically, I was thinking about some sort of attribute that would enable this behavior. Is this something worth considering for the Web Applications spec? Apparently the CSS group is considering applying the 'pointer-events' property to HTML content as well as SVG, so this is an issue for the www-style mailing list now. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Semantic elements and spec complexity
On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson i...@hixie.ch wrote: , default header, footer, and navigation to having a slightly darker background than their parent element It seems like there should be something more obvious that could be done for these elements. For header and footer a border below and above, respectivly, would seem obvious. That would be simple enough, I guess; what do other people think? I think many authors hate default styles so much that they either prefer to just use div or they start their style sheet with resetting the defaults. Since header is intended to be useful to make subheaders not appear in the ToC, the move from h1Foo/h1 h2Bar/h2 to header h1Foo/h1 h2Bar/h2 /header shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with img border=0). -- Simon Pieters Opera Software
Re: [whatwg] [html5] Semantic elements and spec complexity
On Tue, 10 Feb 2009, Simon Pieters wrote: On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson i...@hixie.ch wrote: , default header, footer, and navigation to having a slightly darker background than their parent element It seems like there should be something more obvious that could be done for these elements. For header and footer a border below and above, respectivly, would seem obvious. That would be simple enough, I guess; what do other people think? I think many authors hate default styles so much that they either prefer to just use div or they start their style sheet with resetting the defaults. Since header is intended to be useful to make subheaders not appear in the ToC, the move from h1Foo/h1 h2Bar/h2 to header h1Foo/h1 h2Bar/h2 /header shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with img border=0). Yeah, that's a good point. I've left it at just display:block. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video playback quality metric
Jeremy Doig wrote: Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well.Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? It seems like, in the short term at least, the worse is better solution to this problem is for content providers to provide links to resources at different quality levels, and allow users to choose the most appropriate resource based on their internet connection and their computer rather than having the computer try to work it out for them. Assuming that the majority of users use a relatively small number of sites with the resources to provide multiple-quality versions of their videos and use a small number of computing devices with roughly unchanging network conditions (I imagine this scenario applies to the majority of non-technical), they will quickly learn which versions of the media works best for them on each site. Therefore the burden of this simple approach on end users does not seem to be very high. Given this, I would prefer automatic quality negotiation be deferred to HTML6.
Re: [whatwg] [html5] Semantic elements and spec complexity
Since header is intended to be useful to make subheaders not appear in the ToC, the move from h1Foo/h1 h2Bar/h2 to header h1Foo/h1 h2Bar/h2 /header shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with img border=0). Yeah, that's a good point. I've left it at just display:block. Four-and-a-bit years on I tend to agree :)
Re: [whatwg] MediaModeAbstractView and changing of media dynamically
On Wed, 20 Sep 2006, Anne van Kesteren wrote: On Tue, 19 Sep 2006 23:27:12 -, Joao Eiras joao.ei...@gmail.com wrote: So, I suggest the creation of the 'media-change' event, which will fire when the UA changes media, having the document as target. The event object could be an instance of a UIEvent, and have 2 extra properties: newMediaMode, and oldMediaMode. This has already been suggested multiple times on this list. Personally, I think a better place is probably the new CSSOM (whenever I get around to it...). I agree that this would be better in CSSOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video playback quality metric
On Tue, 10 Feb 2009 04:38:01 -0500, James Graham jgra...@opera.com wrote:
Jeremy Doig wrote:
Measuring the rate at which the playback buffer is filling/emptying
gives a
fair indication of network goodput, but there does not appear to be a
way to
measure just how well the client is playing the video itself. If I have
a
wimpy machine behind a fat network connection, you may flood me with HD
that
I just can't play very well. The cpu or video card may just not be able
to
render the video well.Exposing a metric (eg: Dropped Frame count,
rendered
frame rate) would allow sites to dynamically adjust the video which is
being
sent to a client [eg: switch the url to a differently encoded file] and
thereby optimize the playback experience.
Anyone else think this would be good to have ?
It seems like, in the short term at least, the worse is better
solution to this problem is for content providers to provide links to
resources at different quality levels, and allow users to choose the
most appropriate resource based on their internet connection and their
computer rather than having the computer try to work it out for them.
Assuming that the majority of users use a relatively small number of
sites with the resources to provide multiple-quality versions of their
videos and use a small number of computing devices with roughly
unchanging network conditions (I imagine this scenario applies to the
majority of non-technical), they will quickly learn which versions of
the media works best for them on each site. Therefore the burden of this
simple approach on end users does not seem to be very high.
Given this, I would prefer automatic quality negotiation be deferred to
HTML6.
Flash has low, medium and high quality that the user can change (although a lot of
sites/players seem to rudely disable that option in the menu for some reason). This helps
out a lot and can allow a video to play better. I could imagine an Auto
option too that automatically switched quality as necessary to get decent playback.
As an event, a site could use it like:
video.onplaybacktooslow = function() {
this.quality = low;
this.setToNativeSize(); // stretched videos use more cpu
};
Or, something like that.
--
Michael
Re: [whatwg] Hyphenation
On Tue, 9 Jan 2007, �istein E. Andersen wrote: Hyphenation does not seem to have been discussed on this list so far, and I think it should be. Old proposal: [2] http://www.nada.kth.se/i18n/html/hyph.html While I appreciate the problems faced by Swedish, German, and othes, I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Given that Unicode provides soft hyphen semantics and CSS provides the rendering rules, I don't think there is anything much for HTML5 to say on the matter at this time. This thread included many further e-mails discussing the subject. I agree with most of the points made. There did not seem to be a consensus that this is something that HTML5 should do anything about. If hyphenation dictionaries are to be used, it seems CSS would be the best place for them. I haven't done anything in HTML5 to handle them. As usual, please let me know if there is something I missed. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Ideas regarding Web Applications 1.0
On Mon, 12 Mar 2007, Nicholas Shanks wrote: On 28 Feb 2007, at 05:38, Ian Hickson wrote: For example, your page-wide header might need shortening on handheld media. I don't have a good proposal for this. Maybe we need the opposite of abbr? We already have the opposite of the abbr element. It's called� the abbr attribute (for th elements). And yes, it would be nice, though not really essential, if there were a blessed mechanism for specifying different titles for different display media. This can be achieved through CSS media queries CSS3's content property at present, and I don't think the usage case is sufficient to warrant an extension of HTML. Agreed. I haven't added anything for this case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How to improve the appearance of web pages
On Tue, 13 Mar 2007, Behnam ZWNJ Esfahbod wrote: Implementing a new web application from scratch, I found out some new ideas to make the appearance of site better. I'm not sure here are the best place for this discussion, but at least it's not out of interest. First one is how Mozilla/Firefox do the zooming thing, Text Size. On web sites with images, changing the text size just works for +/- 2 levels. More than that the whole page gets out of shape. Seems Gecko 1.9/Firefox 3 is going to resize images, but I'm not sure. BTW the first trick is how to make images zoomable, by the ratio of Text Size. I set an style attribute for each image (which are not a lot, limited to the logos) which sets font-size to image's width (in pixel) and set the image's width to 1em. It works well on Fx2.0 and IE6. The problem is there's no way to do it globaly, and I should add a style attribute to each img tag. Something I found weird is the default unit of images without width and height attributes. If there was a way to just set the default unit of images to em, the problem could be solved. The problem is better solved using actual pixel zoom, rather than text zoom. Most browsers do this now. The second one is to get the web server decide which image file is better. An Apache httpd module can select the best response for a request for image the-company-logo if it knows which size is needed, and what mime-types are acceptable. My idea is to add a field to the http request header for image files, to let the server know which size the image is going to be shown, and then it decides to send the best answer. [...] Another usage is when the browser does the zooming. When I zoom in the page 200%, that's good if browser can get the company logo with better quality. It would be just another request for the-company-logo with the 384 pixels width, and it may be a bitmap or vector file again. [...] I recommend bringing this up with the HTTP working group, as it seems out of scope for HTML5. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hyphenation
Ian Hickson schrieb: On Tue, 9 Jan 2007, �istein E. Andersen wrote: Hyphenation does not seem to have been discussed on this list so far, and I think it should be. Old proposal: [2] http://www.nada.kth.se/i18n/html/hyph.html While I appreciate the problems faced by Swedish, German, and othes, I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Jukka Korpela stated that the intention of the soft hyphen is not actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html (Anyway I don't really understand the difference between a normal hyphen and a soft hyphen then...) Given that Unicode provides soft hyphen semantics and CSS provides the rendering rules, I don't think there is anything much for HTML5 to say on the matter at this time. This thread included many further e-mails discussing the subject. I agree with most of the points made. There did not seem to be a consensus that this is something that HTML5 should do anything about. If hyphenation dictionaries are to be used, it seems CSS would be the best place for them. I haven't done anything in HTML5 to handle them. The wish for an in-text hyphenation mechanism is of course motivated by the habit of how we do it in office and layout softwares, where text and presentation are not separated. I totally agree that the appropriate place for it is presentation, thus CSS, and the CSS3 draft looks quite reasonable: http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation Anyway I don't find anything about the format of the hyphenation dictionary. To replace in-text hyphenation hints it is necessary to have several levels of hyphenation quality - the german word for hyphenation mechanism for example, Trennungsmechanismus, you might want to have hyphentated at any possible place inside body text, but only at Trennungs-mechanismus in a headline. I see that this list is not the appropriate place for suggestions about CSS3 properties - maybe someone can point me to the appropriate place?
Re: [whatwg] Hyphenation
On Tue, 10 Feb 2009, Markus Ernst wrote: While I appreciate the problems faced by Swedish, German, and othes, I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Jukka Korpela stated that the intention of the soft hyphen is not actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html As far as I can tell this is a non-issue; HTML5 defers to Unicode for the semantics of its characters, and Unicode is clear here. HTML5 doesn't support ISO 8859-1 (it always treats content labeled as such as a Win1252 mapping to Unicode). The wish for an in-text hyphenation mechanism is of course motivated by the habit of how we do it in office and layout softwares, where text and presentation are not separated. I totally agree that the appropriate place for it is presentation, thus CSS, and the CSS3 draft looks quite reasonable: http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation Anyway I don't find anything about the format of the hyphenation dictionary. To replace in-text hyphenation hints it is necessary to have several levels of hyphenation quality - the german word for hyphenation mechanism for example, Trennungsmechanismus, you might want to have hyphentated at any possible place inside body text, but only at Trennungs-mechanismus in a headline. I see that this list is not the appropriate place for suggestions about CSS3 properties - maybe someone can point me to the appropriate place? www-st...@w3.org is the appropriate place. See the Status of this document section of the draft you cite above. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hyphenation
Markus Ernst writes: Ian Hickson schrieb: I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Jukka Korpela stated that the intention of the soft hyphen is not actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html He claims that there are multiple standards that contradict each other. So whatever is implemented is bound to contravene at least one of them. However he mentions that: * HTML 4 defines it as a hyphenation hint. * Unicode defines it as a hyphenation hint. * Recent browsers are now treating it as a hyphenation hint. * The contradictory standard (ISO-8859) only defines a soft hyphen when used at the end of a line, namely that it should be rendered like a hyphen. Since that standard doesn't envisage the character being used elsewhere, it is silent on how it should be rendered. It seems to me that choosing to render invisibly a soft hyphen which isn't at the end of a line doesn't contradict the text of ISO-8859 (though it could be argued to contradict its spirit). (Anyway I don't really understand the difference between a normal hyphen and a soft hyphen then...) Suppose you are reflowing some text (perhaps because you are quoting it); words which were broken over lines in the original may want rejoining into a single word in your version (that is, the soft hyphen disappears); but hyphens (non-soft) between two words need to remain. Smylers
Re: [whatwg] Default (informal) Style Sheet
On Tue, 10 Feb 2009 11:52:32 +0100, Ian Hickson i...@hixie.ch wrote: Speaking of hr, having a default style for it would increase interoperability (if only in the presentation layer) a great deal. Done. Excellent! -- Asbjørn Ulsberg -=|=- asbj...@ulsberg.no «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Video playback quality metric
On Tue, Feb 10, 2009 at 1:54 AM, Michael A. Puls II shadow2...@gmail.com wrote: Flash has low, medium and high quality that the user can change (although a lot of sites/players seem to rudely disable that option in the menu for some reason). This helps out a lot and can allow a video to play better. I could imagine an Auto option too that automatically switched quality as necessary to get decent playback. Isn't that rendering quality? That can of course be adjusted by the browser, dynamically and/or according to a user setting, with or without a javascript interface. -r
Re: [whatwg] Color attributes
On Thu, 16 Oct 2008, Simon Pieters wrote: Color attributes in HTML have special processing. [...] It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes The spec now defines this. Thanks for your work on this. It was hugely helpful. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Load SVG via IMG element
On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote: I noticed that Opera 9.5 can load an SVG image via the IMG element. I think this is a wonderful thing. Is there any specification on how this should work? For example, I noticed that Opera, for some reason, does not scale SVG images to fit the box created by the IMG element's width and height attributes. Here is a test page: http://xhtml.com/misc/svg-img.htm Can someone please point me to any specs on loading SVG via IMG element? On Fri, 5 Oct 2007, Devi Web Development wrote: My understanding is that SVG should not be scaled to fit given dimensions because scaling information is provided in the SVG itself. I don't know about the full status of SVG in browsers, but I know that Firefox supports some, and the Adobe plug-in is common. A full test suite is available at http://www.w3.org/Graphics/SVG/Test/ A specification for embedding SVG in XHTML can be found at http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some documentation at http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction It's not clear to me what I should say in HTML5 about this. img should just do whatever the image format says it should do, right? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [HTML5] Accessibility question
On Sat, 22 Mar 2008, Nicholas C. Zakas wrote: Apologies for not replying sooner, I've been struck with a bit of the flu. The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. For example, our accessibility guidelines at Yahoo! say that every unordered list (ul) should be preceeded by a header that describes its use. The header may say something like Page options or Available styles and we use CSS tricks (text-indent: -1px;) to hide these headings from display while allowing screen readers to read them. To sighted users, the meaning of the list is apparent because they can see the visual treatments we've applied whereas blind users would just hear a list read out of context. Another example is for buttons that make use of sprites. Something is implemented as a link but with a background image that's part of a sprite. The link needs to have descriptive text for screen readers but the text is unnecessary for sighted users as they can see the image. For example: a href=# class=closespanClose/span/a For things like this, I usually end up using the same CSS trick mentioned above to move the Close text out of the way. Just looking at the HTML, it's not apparent that Close is not intended to seen. Whereas the following clears it up: a href=# class=closespan noviewClose/span/a Now I know from looking at the source code that Close is clearly not intended to be seen. This seems like a CSS problem. The text is only inapplicable because of the CSS, right? If the CSS wasn't applied, then even on a screen, the user would need the titles or button text you've described. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
On Mon, 10 Nov 2008, Paul Arzul wrote: is it unfortunate that the html4 stylesheet is only informative? perhaps html5 could then consider giving us a normative default user agent stylesheet - or at least a normative version with only display properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=image width/height attributes
On Tue, 23 Dec 2008, Kartikaya Gupta wrote: Are there any plans to add the width/height attributes for the input element to the HTML5 spec? It seems that all browsers (Opera, FF, Safari, IE) support width/height on input type=image in both quirks and standards mode. There are websites that depend on this behavior (the select-your-postal-code landing page at canadiantire.ca is one example) and it doesn't seem to be specced anywhere that I could find. They're specified now. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
Ian Hickson wrote: On Mon, 10 Nov 2008, Paul Arzul wrote: is it unfortunate that the html4 stylesheet is only informative? perhaps html5 could then consider giving us a normative default user agent stylesheet - or at least a normative version with only display properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. Could that arguably be considered to be a machine-generated user stylesheet? I tend to think of the settings my browser has for choosing default fonts and so forth to be functionally equivalent to me writing a user stylesheet that contains the same settings. This would allow the HTML spec to normatively require browsers to use a particular default stylesheet (or, indeed, act as if they've done so) while still allowing for user-specific alterations of various kinds. (I believe that Mozilla is already implemented as above, more or less.)
Re: [whatwg] Load SVG via IMG element
In the message below, Ian Hickson wrote: It's not clear to me what I should say in HTML5 about this. img should just do whatever the image format says it should do, right? I would think so, but I cc-ed Doug Schepers on this who might know of a reason not to. I seem to recall some discussion of this somewhere, but if you didn't find it, Ian, then I doubt that I could. David btw, though off-topic here, the question from Vlad about browser support can be answered from Jeff Schiller's up-to-date info on implementations of the SVG spec at http://www.codedread.com/svg-support.php . In brief, all major browsers are implementing quite a bit of SVG natively now except for IE which still relies on a third party plugin. Opera does almost all of SVG1.1 and WebKit is quite far along with SMIL (SVG animation). - Original Message - From: Ian Hickson i...@hixie.ch To: Vlad Alexander (xhtml.com) vlad.alexan...@xhtml.com; Devi Web Development devi.webmas...@gmail.com Cc: wha...@whatwg.org Sent: Tuesday, February 10, 2009 8:15 PM Subject: Re: [whatwg] Load SVG via IMG element On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote: I noticed that Opera 9.5 can load an SVG image via the IMG element. I think this is a wonderful thing. Is there any specification on how this should work? For example, I noticed that Opera, for some reason, does not scale SVG images to fit the box created by the IMG element's width and height attributes. Here is a test page: http://xhtml.com/misc/svg-img.htm Can someone please point me to any specs on loading SVG via IMG element? On Fri, 5 Oct 2007, Devi Web Development wrote: My understanding is that SVG should not be scaled to fit given dimensions because scaling information is provided in the SVG itself. I don't know about the full status of SVG in browsers, but I know that Firefox supports some, and the Adobe plug-in is common. A full test suite is available at http://www.w3.org/Graphics/SVG/Test/ A specification for embedding SVG in XHTML can be found at http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some documentation at http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction It's not clear to me what I should say in HTML5 about this. img should just do whatever the image format says it should do, right? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
On Tue, 10 Feb 2009, Martin Atkins wrote: Ian Hickson wrote: On Mon, 10 Nov 2008, Paul Arzul wrote: is it unfortunate that the html4 stylesheet is only informative? perhaps html5 could then consider giving us a normative default user agent stylesheet - or at least a normative version with only display properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. Could that arguably be considered to be a machine-generated user stylesheet? Does it make any difference? The net result is that the user and the author can't rely on a single style sheet. What benefit would a definite UA style sheet be, if not that? This would allow the HTML spec to normatively require browsers to use a particular default stylesheet (or, indeed, act as if they've done so) while still allowing for user-specific alterations of various kinds. There wouldn't be much point to that requirement, since it couldn't be usefully tested. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 4:53 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking: So it behaves different from passing in an empty string? For some functions this surprises me, such as for the namespace parameter for getAttributeNS, I would think that we there treat the same as null. Not necessarily, but I agree that would be a better thing to report. I'll rejig the tests to get that information. Cameron McCormack: OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? converting a valid value of the type to a different value of that type, which values exactly? null. It feels slightly strange to me to treat null as a second class value by default. But I'll get over it. :-) The point would be to not do it by default. I.e. default behavior is to treat null as a valid value that is left untouched by default. And only convert it to n-u-l-l when specified in IDL. To answer your original question. I think the most important thing is to have few exceptions that authors have to learn. It may actually be indicative of a need for two distinct types: strings (i.e., possibly empty sequences of characters) and strings-or-null. But I don't know if it's worth rewriting everything in this way. Yeah / Jonas
Re: [whatwg] [html5] Rendering of interactive content
On Sat, 7 Feb 2009, Giovanni Campagna wrote: 2009/2/6 Ian Hickson i...@hixie.ch On Fri, 6 Feb 2009, Giovanni Campagna wrote: I'm proposing to replace the current rendering mechanism, based on Behavioural Extension to CSS, that in turn is based on XBL2, with something based on the CSS3 Basic User Interface (css3-ui), ie replacing the binding: property with appropriate appearance: property directly on the element, instead of relying on the binding itself. The two properties are orthogonal -- 'binding' sets the behavior, 'appearance' sets the look-and-feel. I thought about it later, and I realized that you cannot style complex widgets without XBL (or something like that) because pseudo-elements are not reached by events. If they ever would, we would have horrible situations we have now. So for complex widgets (Number, File, Slider) it may be impossible to avoid a binding property, but anywhere it is possible you should try to use the available (appearance, content, icon, etc.). Even when using those, the author is able to shut them down, and knows perfectly which of them apply (they're defined normatively in HTML5 and they're exposed by browser tools for web dev). This allows for them to be selectively disabled, eg. to show BB without a button but with the native icon. As far as I know I've only used 'binding' where it is necessary. Note that bb only uses the binding if it's not empty. What is more important, is that appearance normatively defines what properties from outside the appearance definition are allowed to interfere with the native look of the widget, binding does not. If author style sheets are not imported in XBL (apply-author-sheets=false), they don't apply at all. I'm not sure what you mean when you say 'binding' doesn't define this -- as far as I can tell, XBL2 fully defines what should happen here. We can't really know ahead of time whether the bindings should have apply-author-sheets=false or true, though. The advantage of appearance vs binding is that: 1) you don't need an additional pass before applying the correct platform-specific widget style With UA-native bindings, you wouldn't need an additional pass either. The current spec says User agents are encouraged to make their bindings set the 'appearance' CSS property appropriately to achieve platform-native appearances for widgets: this means that the binding should set appearance, and then appearance should make the widget look like a normal button. I wouldn't characterise that as an extra pass, but ok. I don't think it's a problem. 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD BECSS is actually probably more stable than CSS3 UI at this point. Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is final, and waiting only for implementation. CSS3 UI is very vague, and is going to need serious work before browsers are able to actually implement it properly. A lot of the vendor feedback at the time it was written was dismissed (e.g. it doesn't have a particularly useful or comprehensive list of appearances). 3) you don't block the binding property: I don't expect that applying an XBL binding on an element causes it to appear like a span (because it gets almost no default CSS) This is actually intentional. Experience with elements like fieldset that have styles that aren't expressed in CSS is that you end up not being able to restyle them properly if you desire. With 'binding' we'd be able to knock out the whole default rendering (including weird things with the children) in one go. The fact is that binding it the best way to apply a set of event handlers to an element. Having to tweak the computed style of a fieldset in order to find what properties are actually set and reproduce them in the binding, just to put a set of onchange handlers to lots of fieldset, does not look optimal. I don't understand why you would need to know what properties are set, or what 'onchange' has to do with anything here. 4) you keep the appearance property working: current UA (Firefox and Safari at least) already implement appearance, and correctly set it on the input element. This could no longer be possible using XBL, because of the CSS inheritance model inside XBL (if you apply to appearance to some part of the shadow tree, it is not visible on the bound element) I don't understand what you mean here. I mean that Firefox and Safari set the appearance property on the widget element, and it is visible from outside, and dynamically changeable at run time. The binding property instead contains an opaque and UA specific value, that is not intended to be changed from JS (to switch back and forth between widget types) I expect we'll define actual
[whatwg] Author control over media preloading/buffering
When a media element loads, reaches the HAVE_CURRENT_DATA state, but is paused, and 'autoplay' is not set, we have to decide whether to keep downloading data or not. If we expect the user to play the stream, we should keep downloading and buffering data to minimize the chance that buffering will be needed during playback. But if we don't expect the user to play the stream, we should pause the download to conserve resources. The latter is especially important on pages with large numbers of media elements, only one or two of which the user will play. In general it's hard to see how to make a good guess automatically. If a page has one (non-autoplay) media element on it, it's hard to know whether the user is expected or not expected to play it. For example the user might be expected to play it, but only after they've read some text before the video (so autoplay is not appropriate). I think (but I'm not sure) that authors are likely to be able to make better guesses, so I think it would be useful to provide authors with control over this decision. I think that authors are likely to want this control in the same way they like to be able to preload images. So, how about adding an autobuffer attribute, which instructs the browser that the user will probably play the video and as much data as possible should be pre-downloaded? By default (when the attribute is not present) the browser would be expected to pause the download after reaching HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Color attributes
On Wed, 11 Feb 2009 01:22:59 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 16 Oct 2008, Simon Pieters wrote: Color attributes in HTML have special processing. [...] It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes The spec now defines this. It seems the spec lacks the CSS2 system colors and 'transparent'. -- Simon Pieters Opera Software
