Re: [whatwg] Reverse ordered lists
Robert (Jamie) Munro wrote: Simon Pieters wrote: See: http://forums.whatwg.org/viewtopic.php?t=130 Siemova wrote: I recently wanted to create an OL in reverse order. In scouring the web for a solution, I found no simple way to accomplish this, but came across a number of other people frustrated by the lack of this minor feature. The easiest, most obvious solution would be to create an attribute for Ordered Lists -- let's call it order= -- which would have two possible values: ftl (first to last) and ltf (last to first). (A boolean reverse= attribute or so would also work, I guess.) How about a step attribute that is allowed to be negative? That way: ol step=-1 liA/li liB/li /ol would be: 2. A 1. B How would incremental rendering work? Imagine the following page ol step=-1 liA/li liB/li liC/li liD/li liE/li liF/li /ol If the browser has only received the first three items it would render 3. A 2. B 1. C a couple of seconds later it receives the rest of the page. It would then have to renumber all so far rendered items. This would look very strange to the user watching the page as it's loading. This problem is even worse if the paragraph above contains something like: Make sure to turn on the power after step 2 below. / Jonas
[whatwg] More random comments on the putImageData definition
Yet more commentary: I noticed that the behaviour is undefined if putImagedata is provided an ImageData object on which the width, height, or data member is a getter that throws an exception. A quick check shows that FFX3 throws a type mismatch -- eg. acts as though the field was invalid. Ooh, and a request for a feature. It would be great if putImageData could take a source region, in addition to the destination. One of the primary reasons for using get/putImageData is to allow JS to rapidly blit data to the screen, however without an ability to blit only a subregion of the image data the only available options are to either re-blit the entire imagedata region (which can be expensive due to the need for [un]premultiplying in some (all?) implementations), or create and populate a new ImageData object which still requires more work than would ideally be necessary. --Oliver
Re: [whatwg] meta http-equiv=X-UA-Compatible content=IE=edge /
Christoph Päper wrote: Brenton Strine: (...) IE8 'passes' the Acid2 test, but (...) won't render pages with the new standards-compatibility unless you explicitly tell it to with this meta tag: meta http-equiv=X-UA-Compatible content=IE=edge / Note that 'edge' is actually discouraged and authors should instead provide version numbers they successfully tested their documents in. (The list may get rather long and incomplete over time, but the QA department can finally show off.) !--[if gte IE 8] meta http-equiv=X-UA-Compatible content=IE=edge / ![endif]-- This is just ridiculous now. Why can't MS just use gecko and focus on their UI??
Re: [whatwg] meta http-equiv=X-UA-Compatible content=IE=edge /
Brenton Strine wrote: [IE8] won't render pages with the new standards-compatibility unless you explicitly tell it to with this meta tag: meta http-equiv=X-UA-Compatible content=IE=edge / My thought is this (and I'm hoping other people will come up with better ideas). Give HTML the ability to declare specific technologies that it uses, such that if a browser supports that technology, it makes use of it. Sort of like using object detection in javascript instead of messing with the user agent string. For example, assume an amazing new image format comes out called AwesomeImg--Opera 11 supports it, but you're not sure when IE will. Maybe IE10. But you don't want to lock your site into IE10 mode because it might break in IE10, or IE10 might still not support all your features but IE11 would have. A feature like that would target a different problem: the problem that author knows which features are available in different standards but user agents do not yet support those features. The problem with this method is that UAs may support CSS 2.1 and advertise it but there are bugs. Some content that has been designed for CSS 2.1 would not display correctly if the UA supports CSS 2.1 but has some - perhaps minor - bug in the implementation. The X-UA-Compatible fights with the problem that content authors have no clue about standards and think that if their content looks correct to them when they try user agent X, then it's fine. The X-UA-Compatible is designed so that the content author lists the UAs that he has confirmed to display the content correctly. I think the idea is pretty good but the IE8's implementation is terrible. Instead of the currently proposed solution the author should add X-UA-Compatible: IE=7 to their HTTP headers if they have checked with IE7. IE8 should use its best standards mode by default and downgrade to IE7 rendering if and only if the page says that it has been tested only with IE7. The DOCTYPE switch should be used to switch to real quirks mode for obviously non-standard content. As it has been currently designed, the feature must be used to get the best (nearest to the standard) rendering possible instead of requesting a special set of quirks which is really needed for old and somewhat incorrectly authored content. X-UA-Compatible: IE=X should be considered to mean I don't know what I'm doing but nevertheless the content looks the way I meant if you use Internet Explorer version X. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 10:41:25 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: How would incremental rendering work? Imagine the following page ol step=-1 liA/li liB/li liC/li liD/li liE/li liF/li /ol If the browser has only received the first three items it would render 3. A 2. B 1. C a couple of seconds later it receives the rest of the page. It would then have to renumber all so far rendered items. This would look very strange to the user watching the page as it's loading. That's an interesting point, but I don't see it as a show-stopper. Either you allow it to have the wrong numbers while loading, or you make reverse ordered lists block layout for a while, or we could use something along the lines of: ol count-down-from=6 ...which is more of a pain to author but at least can render correctly incrementally. This problem is even worse if the paragraph above contains something like: Make sure to turn on the power after step 2 below. Instructions are seldom put in reverse order. ;-) -- Simon Pieters Opera Software
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 13:35:38 +0100, Simon Pieters [EMAIL PROTECTED] wrote: That's an interesting point, but I don't see it as a show-stopper. Either you allow it to have the wrong numbers while loading, or you make reverse ordered lists block layout for a while, or we could use something along the lines of: ol count-down-from=6 ...which is more of a pain to author but at least can render correctly incrementally. I completely forgot about the start='' attribute. :-) If incremental rendering is an issue (e.g. if you use a list that will always have 100 items) the author can just set the start value explicitly: ol start=100 reverse The lack of start='' would make the numbers update as the list is filled with lis. This allows both for simplicitly for short lists and correct incremental rendering for large lists. -- Simon Pieters Opera Software
[whatwg] How to use SVG in HTML5?
Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? - d.
Re: [whatwg] More random comments on the putImageData definition
On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote: It would be great if putImageData could take a source region, in addition to the destination. One of the primary reasons for using get/putImageData is to allow JS to rapidly blit data to the screen, however without an ability to blit only a subregion of the image data the only available options are to either re-blit the entire imagedata region (which can be expensive due to the need for [un]premultiplying in some (all?) implementations), ((Opera does non-premultiplied colour internally.)) or create and populate a new ImageData object which still requires more work than would ideally be necessary. You can also create a temporary canvas and putImageData once onto that, and then drawImage sections onto the screen as they are needed. That lets you draw lots of sections lots of times quickly (since you're mostly drawing from the optimised canvas surface format, not from a JS array), which perhaps helps in some (most?) of the cases. (You still have to do a single putImageData of the whole data to get it onto the temporary canvas, but if there are parts of the data you aren't ever using then you just should make the ImageData smaller and cut out the unused bits.) -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Reverse ordered lists
At 15:03 +0100 23/01/08, Lachlan Hunt wrote:
Simon Pieters wrote:
ol start=100 reverse
The lack of start='' would make the numbers update as the list is
filled with lis. This allows both for simplicitly for short lists
and correct incremental rendering for large lists.
No, the lack of an explicit start attribute would make it start from
the default value: 1. It would then count down from there:
1. A
0. B
-1. C
-2. D
which suggests a pair of orthogonal attributes, as above, the
direction ('order'='increasing' or 'decreasing'??) and the initial
ordinal value (which should be a number, even if the styling asks for
e.g. alphabetic labelling).
perhaps
(from a non-expert)
--
David Singer
Apple/QuickTime
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 15:03:42 +0100 Lachlan Hunt [EMAIL PROTECTED] wrote: Simon Pieters wrote: ol start=100 reverse The lack of start='' would make the numbers update as the list is filled with lis. This allows both for simplicitly for short lists and correct incremental rendering for large lists. No, the lack of an explicit start attribute would make it start from the default value: 1. It would then count down from there: 1. A 0. B -1. C -2. D Actually, the best route I can see is to not have a start attribute at all but to rely on the browser to automatically detect the amount of li tags within an ol reverse container and decrement from there. ie: ol reverse -- Start count from here. liRed/li liOrange/li liYellow/li liGreen/li liBlue/li /ol -- Close tag detected, 5 li tags counted. is rendered as starting from 5: 5. Red 4. Orange ...etc... and using a step value, for example, all the browser would need to do is multiply the total at the /ol tag, and decrement that multiplied total by the step amount, making: ol reverse step=5 render the list as: 25. Red 20. Orange 15. Yellow ...etc... It might mean more work for the browsers, but by experience something like this isn't too hard to implement.
Re: [whatwg] How to use SVG in HTML5?
David Gerard wrote: Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported, although several people have expressed an interest in changing that. However there are significant technical barriers to overcome at the syntax/parser level. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, James Graham [EMAIL PROTECTED] wrote: In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? - d.
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 15:03:42 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Simon Pieters wrote: ol start=100 reverse The lack of start='' would make the numbers update as the list is filled with lis. This allows both for simplicitly for short lists and correct incremental rendering for large lists. No, the lack of an explicit start attribute would make it start from the default value: 1. It would then count down from there: 1. A 0. B -1. C -2. D Why? From an authoring perspective I would say that it's more useful to have the last item be 1 by default. -- Simon Pieters Opera Software
Re: [whatwg] Reverse ordered lists
But then what would someone do in order to begin a list but not end it? For instance, if they wanted to say: 10. Blah 9. Blah 8. Blah And so forth... I guess I'm asking, why recommend artificial and unnecessarily narrow constraints? We don't want UAs to force unexpected behaviors which would frustrate the end user and make them search (vainly) for a workaround if that's not what they wanted, do we? Personally, I don't see any problem with allowing list items to be numbered 0 or negatively, so I think the 1, 0, -1, -2 default approach would work fine. With both reverse and step we could still accomplish what you're talking about, but the spec would remain both simpler for UAs to implement and more flexible for content creators' use. - Jason On Jan 23, 2008 8:23 AM, Sam Arthur Allen [EMAIL PROTECTED] wrote: Actually, the best route I can see is to not have a start attribute at all but to rely on the browser to automatically detect the amount of li tags within an ol reverse container and decrement from there. ie: ol reverse -- Start count from here. liRed/li liOrange/li liYellow/li liGreen/li liBlue/li /ol -- Close tag detected, 5 li tags counted. is rendered as starting from 5: 5. Red 4. Orange ...etc... and using a step value, for example, all the browser would need to do is multiply the total at the /ol tag, and decrement that multiplied total by the step amount, making: ol reverse step=5 render the list as: 25. Red 20. Orange 15. Yellow ...etc... It might mean more work for the browsers, but by experience something like this isn't too hard to implement.
Re: [whatwg] How to use SVG in HTML5?
David Gerard wrote: On 23/01/2008, James Graham [EMAIL PROTECTED] wrote: In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? I believe it works in Opera's preview builds. http://my.opera.com/desktopteam/blog/ First publicly announced on the 12th October It is now possible to use an SVG image in an IMG element as well as specify one as a background image in CSS http://my.opera.com/desktopteam/blog/2007/10/12/neat-thumbnails-instant-searching-and-more
Re: [whatwg] Reverse ordered lists
Ah, yes, true enough. For a moment I forgot that. Thank you for pointing it out. So default would logically be for the numbering to end at 1. Thus, the code ol reverse liRed/li liOrange/li liYellow/li liGreen/li liBlue/li /ol would display as: 5. Red 4. Orange 3. Yellow 2. Green 1. Blue If you included step=2, it would display this way: 9. Red 7. Orange 5. Yellow 3. Green 1. Blue And, if after that you threw a start=4 onto it: 4. Red 2. Orange 0. Yellow -2. Green -4. Blue I guess that's what I was thinking of when I told Sam I don't see a problem with negative values. But it would only occur in a case where you used a start value which was lower than the step value times the number of list items. Otherwise (to repeat myself) a reversed list would end at 1 by default. Sounds perfectly reasonable to me. - Jason On Jan 23, 2008 8:58 AM, Simon Pieters [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 15:03:42 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Simon Pieters wrote: ol start=100 reverse The lack of start='' would make the numbers update as the list is filled with lis. This allows both for simplicitly for short lists and correct incremental rendering for large lists. No, the lack of an explicit start attribute would make it start from the default value: 1. It would then count down from there: 1. A 0. B -1. C -2. D Why? From an authoring perspective I would say that it's more useful to have the last item be 1 by default. -- Simon Pieters Opera Software
Re: [whatwg] Reverse ordered lists
On Jan 23, 2008 9:32 AM, Sam Arthur Allen [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 09:07:02 -0600 Siemova [EMAIL PROTECTED] wrote: But then what would someone do in order to begin a list but not end it? For instance, if they wanted to say: 10. Blah 9. Blah 8. Blah And so forth... Then in this situation, a start value would be necessary. You're right! My apologies for misreading. Earlier I thought for a moment you were advocating having no start attribute at all. *sheepish grin* Personally, I don't see any problem with allowing list items to be numbered 0 or negatively, so I think the 1, 0, -1, -2 default approach would work fine. I can only disagree with using negative numbers in a reverse order list, since I communicate to many people in non-english countries that use brackets to display negative numbers in their locale. So a list would appear as: 1 : Red 0 : Green (1): Blue (2): Violet (3): ...etc... and if a long list is printed out on paper, all anybody would see is: (120): Insert a really long paragraph of text here. ... (121): And one here too ... which, to someone outside of their locale, would appear confusing. Aha. Well, your intended audience will understand anyway, right? And if any other reader looks at the beginning of the list, or is familiar with the context (surely the author would explain the list in some fashion), they'll know what's going on. Is that scenario really dire enough to prevent negative numbering, particularly given how troublesome and unintuitive it might be to figure out how to number items that should be negative but aren't allowed to display that way? - Jason
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, Anne van Kesteren [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 15:55:27 +0100, David Gerard [EMAIL PROTECTED] wrote: img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? Should work in Opera 9.5 (beta though). If you use object data=foo.svg/object it probably works in more browsers. Works somewhat in SeaMonkey (gives default specified rendering size of image in a small object box with scroll bars) and Safari (gives default size in small box with no scroll bars, i.e. top left corner only) and best in Minefield (scales image to size of object box, scales properly with WIDTH= or HEIGHT=). (Minefield uses 100% CPU just displaying my test image, but also renders the SVG most accurately of any of them - this image was drawn in Omnigraffle but is known to misrender in Firefox, SeaMonkey, Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a copy. I expect I should create a test case and file a lot of bugs ...) Thank you all! - d.
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 16:54:23 +0100, Siemova [EMAIL PROTECTED] wrote: I can only disagree with using negative numbers in a reverse order list, since I communicate to many people in non-english countries that use brackets to display negative numbers in their locale. So a list would appear as: 1 : Red 0 : Green (1): Blue (2): Violet (3): ...etc... and if a long list is printed out on paper, all anybody would see is: (120): Insert a really long paragraph of text here. ... (121): And one here too ... which, to someone outside of their locale, would appear confusing. Not a valid reason to ban negative numbers, IMHO. Is that scenario really dire enough to prevent negative numbering, particularly given how troublesome and unintuitive it might be to figure out how to number items that should be negative but aren't allowed to display that way? Negative numbers aren't really prevented today. It's also interesting how negative numbers and 0 interacts with different list type=''s in different browsers... http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Col%20type%3Da%20start%3D-2%3E%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex It was pointed out to me that the start='' attribute (and the corresponding DOM attribute) currently defaults to 1. This could, AFAICT, reaonably trivially be changed to make it depend on the direction of the list and the number of li children. -- Simon Pieters Opera Software
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 09:54:23 -0600 Siemova [EMAIL PROTECTED] wrote: On Jan 23, 2008 9:32 AM, Sam Arthur Allen [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 09:07:02 -0600 Siemova [EMAIL PROTECTED] wrote: But then what would someone do in order to begin a list but not end it? For instance, if they wanted to say: 10. Blah 9. Blah 8. Blah And so forth... Then in this situation, a start value would be necessary. You're right! My apologies for misreading. Earlier I thought for a moment you were advocating having no start attribute at all. *sheepish grin* That's ok, I should have made myself clear from the start. Personally, I don't see any problem with allowing list items to be numbered 0 or negatively, so I think the 1, 0, -1, -2 default approach would work fine. I can only disagree with using negative numbers in a reverse order list, since I communicate to many people in non-english countries that use brackets to display negative numbers in their locale. So a list would appear as: 1 : Red 0 : Green (1): Blue (2): Violet (3): ...etc... and if a long list is printed out on paper, all anybody would see is: (120): Insert a really long paragraph of text here. ... (121): And one here too ... which, to someone outside of their locale, would appear confusing. Aha. Well, your intended audience will understand anyway, right? And if any other reader looks at the beginning of the list, or is familiar with the context (surely the author would explain the list in some fashion), they'll know what's going on. Is that scenario really dire enough to prevent negative numbering, particularly given how troublesome and unintuitive it might be to figure out how to number items that should be negative but aren't allowed to display that way? It's difficult to say, since I can't give any real world situations where a decremental list has been used with negative numbers. However, I've talked to quite Indonesians who use brackets for numbering. Australia has approximately 20,000,000 people, where Indonesia has around 234,500,000. In Australia, it's a fact that 1 out of 3 families have access to the internet -- in Indonesia, it's more like 9 out of 10. Simply put, Indonesians outnumber Australians when it comes to reading websites. Asian countries are technologically advanced in areas like that. And that's just one situation. With the advent of OLPC and the likes, we'll be seeing more non-english cultures accessing the internet, especially African and Middle-East countries where their numbering system is exotic when compared to our own.
Re: [whatwg] How to use SVG in HTML5?
On Jan 23, 2008, at 9:55 AM, David Gerard wrote: On 23/01/2008, James Graham [EMAIL PROTECTED] wrote: In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). img src=foo.svg is just what I was hoping for, thank you :-) Doesn't yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers it currently does work in? This should also work in WebKit nightly builds (available from http://nightly.webkit.org/ ). -Adam
Re: [whatwg] Referer header sent with a ping?
HTTP auth headers may be required to access the internet (e.g., to pass a request through a proxy server), so this should only apply to the Authorization request header, right? -Darin On Jan 22, 2008 11:27 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 22 Jan 2008, dolphinling wrote: HTML5 doesn't say anything about whether a referer should be sent with the POST generated by a ping. There is a new attack vector a ping opens (as currently being discussed on mozilla.dev.platform) that would be blocked if the referer were not sent. Fixed. I also said to not include Cookies or HTTP auth headers. Legitimate uses can always include whatever information they want in the ping= attribute's value itself. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reverse ordered lists
On Jan 23, 2008, at 11:39 AM, Siemova wrote: Very easily: if start is not specified if not reverse start = 1 else start = number of items * step It's not that simple -- the last line should be start = 1 + ( (number of items - 1) * step) if it's assumed that the last item of the list is numbered one by default. _ David Walbert LEARN NC, UNC-Chapel Hill [EMAIL PROTECTED]
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, David Gerard [EMAIL PROTECTED] wrote: Works somewhat in SeaMonkey (gives default specified rendering size of image in a small object box with scroll bars) and Safari (gives default size in small box with no scroll bars, i.e. top left corner only) and best in Minefield (scales image to size of object box, scales properly with WIDTH= or HEIGHT=). Oh, and Opera 9.50 beta build 9745 for Win32 renders it in a box with scroll bars, and does by far the worst rendering of the original SVG I've seen ... (Minefield uses 100% CPU just displaying my test image, but also renders the SVG most accurately of any of them - this image was drawn in Omnigraffle but is known to misrender in Firefox, SeaMonkey, Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a copy. I expect I should create a test case and file a lot of bugs ...) I shall definitely create a public test case, so as to help Firefox 3 and Opera 9.5 do a good job! - d.
Re: [whatwg] Reverse ordered lists
On Jan 23, 2008 10:54 AM, David Walbert [EMAIL PROTECTED] wrote: It's not that simple -- the last line should be start = 1 + ( (number of items - 1) * step) if it's assumed that the last item of the list is numbered one by default. Alas, we see the ill effects of my hastiness today! I stand happily corrected. In that case, it's even simpler: if start is not specified start = 1 if reverse start += (number of items - 1) * step Here's hoping I haven't missed something obvious again. ^_^ Regardless, I think we've shown it's fairly painless to implement. - Jason
Re: [whatwg] How to use SVG in HTML5?
James Graham wrote: David Gerard wrote: Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported, although several people have expressed an interest in changing that. However there are significant technical barriers to overcome at the syntax/parser level. Supporting img src=foo.svg is a requirement of SVG 1.1 [1] If the user agent includes an HTML or XHTML viewing capability or can apply CSS/XSL styling properties to XML documents, then a Conforming SVG Viewer *must* support resources of MIME type image/svg+xml wherever raster image external resources can be used, such as in the HTML or XHTML 'img' element and in CSS/XSL properties that can refer to raster image resources (e.g., 'background-image') [1] http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGViewers -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Reverse ordered lists
Siemova wrote: On Jan 23, 2008 10:54 AM, David Walbert [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's not that simple -- the last line should be start = 1 + ( (number of items - 1) * step) if it's assumed that the last item of the list is numbered one by default. Alas, we see the ill effects of my hastiness today! I stand happily corrected. In that case, it's even simpler: if start is not specified start = 1 if reverse start += (number of items - 1) * step The problem that Jonas originally pointed out is that, given browsers do incremental rendering number of items is not a known quantity when the list is first rendered. For a pathological example of why this is a problem, imagine a cgi script that just kept spewing out reverse numbered list items, one per second, indefinitely. It may be that in practice lists are short enough that they are typically rendered all in one go so this wouldn't be a problem. I don't think that's obvious, however. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Reverse ordered lists
What about having it render as a standard unordered list ( ie, bulletpoints ) until the entire set of items has been received - and then re-rendering the list as a numbered type, all properly calculated James Graham wrote: Siemova wrote: On Jan 23, 2008 10:54 AM, David Walbert [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's not that simple -- the last line should be start = 1 + ( (number of items - 1) * step) if it's assumed that the last item of the list is numbered one by default. Alas, we see the ill effects of my hastiness today! I stand happily corrected. In that case, it's even simpler: if start is not specified start = 1 if reverse start += (number of items - 1) * step The problem that Jonas originally pointed out is that, given browsers do incremental rendering number of items is not a known quantity when the list is first rendered. For a pathological example of why this is a problem, imagine a cgi script that just kept spewing out reverse numbered list items, one per second, indefinitely. It may be that in practice lists are short enough that they are typically rendered all in one go so this wouldn't be a problem. I don't think that's obvious, however.
Re: [whatwg] Reverse ordered lists
At 17:33 + 23/01/08, Philip Parker wrote: What about having it render as a standard unordered list ( ie, bulletpoints ) until the entire set of items has been received - and then re-rendering the list as a numbered type, all properly calculated how about assuming that if the source wants it numbered, in reverse order, it knows what it is doing, and can tell the browser what number to start at? it still seems the simplest; an attribute that gives the starting number (default 1) and an attribute that gives the direction (increasing or decreasing, default increasing). James Graham wrote: Siemova wrote: On Jan 23, 2008 10:54 AM, David Walbert [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's not that simple -- the last line should be start = 1 + ( (number of items - 1) * step) if it's assumed that the last item of the list is numbered one by default. Alas, we see the ill effects of my hastiness today! I stand happily corrected. In that case, it's even simpler: if start is not specified start = 1 if reverse start += (number of items - 1) * step The problem that Jonas originally pointed out is that, given browsers do incremental rendering number of items is not a known quantity when the list is first rendered. For a pathological example of why this is a problem, imagine a cgi script that just kept spewing out reverse numbered list items, one per second, indefinitely. It may be that in practice lists are short enough that they are typically rendered all in one go so this wouldn't be a problem. I don't think that's obvious, however. -- David Singer Apple/QuickTime
Re: [whatwg] Reverse ordered lists
On Wed, 23 Jan 2008 17:18:56 +0100 Simon Pieters [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 16:54:23 +0100, Siemova [EMAIL PROTECTED] wrote: I can only disagree with using negative numbers in a reverse order list, since I communicate to many people in non-english countries that use brackets to display negative numbers in their locale. So a list would appear as: 1 : Red 0 : Green (1): Blue (2): Violet (3): ...etc... and if a long list is printed out on paper, all anybody would see is: (120): Insert a really long paragraph of text here. ... (121): And one here too ... which, to someone outside of their locale, would appear confusing. Not a valid reason to ban negative numbers, IMHO. On the contrary, I have found that working with people that use a different locale occasionally frustrating. When I copy text from a document that uses a different numbering system, I'm frequently reformatting its text, making work unproductive and time-consuming. For that reason, I constantly try to avoid negative numbers wherever it is unnecessary.
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 17:28 +, James Graham pisze: The problem that Jonas originally pointed out is that, given browsers do incremental rendering number of items is not a known quantity when the list is first rendered. For a pathological example of why this is a problem, imagine a cgi script that just kept spewing out reverse numbered list items, one per second, indefinitely. This is not specific to lists; any content without incremental rendering capability would cause this effect. Chris
Re: [whatwg] Reverse ordered lists
On Jan 23, 2008 12:18 PM, Dave Singer [EMAIL PROTECTED] wrote: how about assuming that if the source wants it numbered in reverse order, it knows what it is doing, and can tell the browser what number to start at? it still seems the simplest: an attribute that gives the starting number (default 1) and an attribute that gives the direction (increasing or decreasing, default increasing). True, that's simplest to implement, but why put the onus on the content author to add things up and specify a start value every time? Computers are for automating such calculations. If you're reversing a list, the default value for start shouldn't be 1 anymore; that should be the ending value, and the starting value ought to be backwards-engineered from it. This is precisely how a content creator would expect it to work. I'm surprised at you, being from Apple as you are. ;) Isn't the idea to make *using* such a function simple and intuitive, even if it has to be a little more complicated on the back-end? - Jason
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 13:42 +, David Gerard pisze: Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? There is none, and there should not be. An IMG element is a replacement for inline text that can be rendered at the viewer's option, an SVG element is an embedded object of its own. SVG is too heavyweight for the purpose of such tiny presentational enhancements. Chris
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 15:15 +0100, Dave Singer pisze:
At 15:03 +0100 23/01/08, Lachlan Hunt wrote:
Simon Pieters wrote:
ol start=100 reverse
The lack of start='' would make the numbers update as the list is
filled with lis. This allows both for simplicitly for short lists
and correct incremental rendering for large lists.
No, the lack of an explicit start attribute would make it start from
the default value: 1. It would then count down from there:
1. A
0. B
-1. C
-2. D
which suggests a pair of orthogonal attributes, as above, the
direction ('order'='increasing' or 'decreasing'??) and the initial
ordinal value (which should be a number, even if the styling asks for
e.g. alphabetic labelling).
perhaps
(from a non-expert)
Ordinal numbers should never be negative; they should always have an
alternative representation using letters (spreadsheet-style).
Negative numbers were first justified because they turned out to be
essential for solving cubic equations; anything less sophisticated can
do without them.
If the start value is too small and the ordinal number descends below 0,
the user agent should leave the remaining items unmarked.
The page will be ill-formed;
the author is obliged to provide a valid value for the start attribute.
The reverse attribute without a tentatively valid start attribute
should be ignored.
Chris
Re: [whatwg] More random comments on the putImageData definition
On 23/01/2008, at 5:44 AM, Philip Taylor wrote: On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote: It would be great if putImageData could take a source region, in addition to the destination. One of the primary reasons for using get/putImageData is to allow JS to rapidly blit data to the screen, however without an ability to blit only a subregion of the image data the only available options are to either re-blit the entire imagedata region (which can be expensive due to the need for [un]premultiplying in some (all?) implementations), ((Opera does non-premultiplied colour internally.)) Righto. There's still the necessary type/range checking involved at some point. or create and populate a new ImageData object which still requires more work than would ideally be necessary. You can also create a temporary canvas and putImageData once onto that, and then drawImage sections onto the screen as they are needed. That lets you draw lots of sections lots of times quickly (since you're mostly drawing from the optimised canvas surface format, not from a JS array), which perhaps helps in some (most?) of the cases. (You still have to do a single putImageData of the whole data to get it onto the temporary canvas, but if there are parts of the data you aren't ever using then you just should make the ImageData smaller and cut out the unused bits.) Yes, there are many ways you can resolve this if you're willing to copy data around in JS, which is far less efficient than letting you use your single backing buffer, but only (effectively) repainting part of it. Using a separate canvas also works, but still requires additional copying, much more memory, and the use of drawImage which doesn't have the same semantics as putImageData. --Oliver -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] How to use SVG in HTML5?
On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ - Sam Ruby
Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 04:19:37 +1100, Mathieu HENRI [EMAIL PROTECTED] wrote: James Graham wrote: David Gerard wrote: ... I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported... Supporting img src=foo.svg is a requirement of SVG 1.1 [1] ... It is true that you can't use inline markup. As far as I know, img src=foo.svg is only supported in Opera 9.5 betas (maybe webkit nightlies, I forget). It's also bad HTML, since it lacks any kind of fallback. But you can use object data-foo.svg/object (again bad HTML, it should generally have some kind of fallback content - and a size). Unfortunately, of course, IE is still holding you back from doing it on the open web that simply :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 06:44:59 +1100, Sam Ruby [EMAIL PROTECTED] wrote: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ An image is not a replacement for text in the real world, only in Ian's current drafts. And where it is, SVG is ideal for having beautifully styled selectable interactive text that is lightweight and easy to create (or heavyweight and bloated if you use something like inkscape, but still easy to create and easy to automagically optimise to something lightweight). Which is why I disagree thoroughly with Chris' assertion here. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, Charles McCathieNevile [EMAIL PROTECTED] wrote: An image is not a replacement for text in the real world, only in Ian's current drafts. And where it is, SVG is ideal for having beautifully styled selectable interactive text that is lightweight and easy to create (or heavyweight and bloated if you use something like inkscape, but still easy to create and easy to automagically optimise to something lightweight). Which is why I disagree thoroughly with Chris' assertion here. FWIW, my use case is to be able to create images in SVG and just use them as ... images, just like I do PNGs or JPEGs. It was also somewhat inspired by setting up rsvg for MediaWiki on our work intranet and wanting to hit it repeatedly with a hammer ... but relying on client-side SVG rendering will have to wait until Firefox 3 renders it not only correctly, but without pegging the processor just displaying ;-) I think Chris is incorrect in his assertion because clients can be presumed to have increasing amounts of rendering power available just to make pretty pictures. Every browser (except IE) *has* SVG rendering. Firefox 3 will have *accurate* SVG rendering. SVG is the Right Thing for so many situations. It's all looking promising to me so far. - d.
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 20:42 +, David Gerard pisze: FWIW, my use case is to be able to create images in SVG and just use them as ... images, just like I do PNGs or JPEGs. It was also somewhat inspired by setting up rsvg for MediaWiki on our work intranet and wanting to hit it repeatedly with a hammer ... but relying on client-side SVG rendering will have to wait until Firefox 3 renders it not only correctly, but without pegging the processor just displaying ;-) I think Chris is incorrect in his assertion because clients can be presumed to have increasing amounts of rendering power available just to make pretty pictures. That does not necessarily mean that the owner of the rendering device would be happy to watch the user agent use that power for something inessential (battery life!). Besides, your paragraph 2 directly contradicts paragraph 1: the implementations are not mature. Every browser (except IE) *has* SVG rendering. And that means that, optimistically, one user in three will have a chance of viewing the content as you intended (unless your target audience is very specific). Firefox 3 will have *accurate* SVG rendering. SVG is the Right Thing for so many situations. It's all looking promising to me so far. While it is nice and comforting to have a promise, it is wise not to rely on it too much. Chris
Re: [whatwg] How to use SVG in HTML5?
On Jan 23, 2008 10:42 PM, David Gerard [EMAIL PROTECTED] wrote: I think Chris is incorrect in his assertion because clients can be presumed to have increasing amounts of rendering power available just to make pretty pictures. please don't assume this. an n800 or n810 does not have much processing power, and its user would prefer that the device's battery last longer. Rendering a tiny picture perfectly on the client side when it could have been rendered server side is not a polite thing to ask of a resource limited device. Every browser (except IE) *has* SVG rendering. That's not true. MicroB as shipped w/ OS 2008 on the N810 (and in OS 2008 for the N800) does not include SVG rendering. http://browser.garage.maemo.org/news/9/ (disclaimer: i wrote that page) AFAICT IE6 included an old version of Adobe's SVG plugin, and you can get Adobe's latest plug-in (3.03) if you like. Firefox 3 will have *accurate* SVG rendering. who's promising this? SVG is the Right Thing for so many situations. It's all looking promising to me so far.
Re: [whatwg] How to use SVG in HTML5?
On 23/01/2008, timeless [EMAIL PROTECTED] wrote: Every browser (except IE) *has* SVG rendering. That's not true. MicroB as shipped w/ OS 2008 on the N810 (and in OS Sorry, you're right. I was thinking only of the desktop. Bad move. Firefox 3 will have *accurate* SVG rendering. who's promising this? Read up the thread. I noted that Minefield's rendering is notably better than FF2's. (I've been exploring the world of SVG in far too much depth lately. All SVG renderers suck, but Minefield's suck is on the CPU-pegging side, not the rendering side.) - d.
[whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
The spec as currently written says that document.domain in a document located at a URI with no domain is null: data:text/html,scriptalert(document.domain);/script Safari and Opera both alert the empty string for this; Firefox alerts null. There's also a domain property on MessageEvent, used with the cross-document postMessage API. The exact value of this property isn't quite clear in the current spec (which says the document has no domain but doesn't say what that translates into on the MessageEvent interface), but Opera and Safari both agree that the domain property should be the empty string when the page that calls postMessage is a data: URL. It seems that, for consistency, document.domain and MessageEvent.domain should both be the empty string in this case, for greatest cross-browser compatibility with the least change to the status quo, with the only change needing to happen in Firefox. Jeff
Re: [whatwg] Reverse ordered lists
On Jan 23, 2008, at 7:10 PM, Robert (Jamie) Munro wrote: Surely it should be numbered with the step. ... 6. Foo 4. Bar 2. Baz I can see either way being useful in theory, but I haven't seen a use case for reverse-ordered list where the the step is not -1 -- nor one with negative-numbered list items. Can anybody cite one or propose one? _ David Walbert LEARN NC UNC-Chapel Hill
[whatwg] nextSiblingElement ?
nextSibling and previousSibling are useful, but not always what I want.
I usually want to get a siblingElement than a sibling, which might be
a text node.
Dom.findNextSiblingElement = function(el) {
for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};
The same is true for childNodes.
It would be useful to have:
nextSiblingElement,
previousSiblingElement,
childElements
Garrett
--
boxbe is annoying-- I use Boxbe to protect my email, so please keep
this code in your reply: JPV9KTNZ
Re: [whatwg] nextSiblingElement ?
Hi Garrett.
Garrett Smith:
nextSibling and previousSibling are useful, but not always what I want.
I usually want to get a siblingElement than a sibling, which might be
a text node.
Dom.findNextSiblingElement = function(el) {
for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};
There is http://www.w3.org/TR/ElementTraversal/, which specifies just
this.
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 15:34 -0600, Siemova pisze: If you mean that a script should be able to use that automatically-generated value, I'm sure that's true, but there are cases wherein the content creator doesn't have access to the script in order to build that in. For example, the very case which inspired me to propose this feature involved a list of items generated in reverse order by a CMS. A CMS is a smart engine, it is not limited to composing content from various sources; it is possible (and probably necessary) to do various fix-ups anyway before sending to the user agent. Chris
