Re: [whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In head)
On Sat, Aug 29, 2015 at 12:51 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Bueller...? Bueller...? This request is almost 5 years old now, but it is even more relevant today, now that web developers are increasingly embracing SVG for purposes of responsive design and accommodating HiDPI displays. Putting SVG defs and other metadata-related elements in HTML's head seems like an obvious choice from a semantic standpoint. But it is currently illegal in the HTML spec because SVG does not distinguish between embedded and metadata content models for its elements, which Hixie has requested so that the HTML spec can simply point to the SVG spec's definitions. (Please see quoted text.) Again, is this something the SVG WG is willing to do? This isn't even something for the SVGWG to decide; it's simply impossible to add new elements to HTML's head. head autocloses when it sees any element that's not title, meta, link, script, or style, and people depend on this behavior - there's definitely pages out there where an svg element is the first content and needs to be displayed. Just put a defs-only svg in the body. Its location doesn't actually matter, it's fine. ~TJ
Re: [whatwg] VIDEO and pitchAdjustment
On Sat, Aug 29, 2015 at 8:18 AM, James Ross ja...@james-ross.co.uk wrote: Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my testing. That's not so hard to implement, but it's also mostly useless since keyframes are often several seconds apart or more. Firefox, Chrome and Safari on desktop and mobile don’t support negative values at all AFAICT. I have notes here suggesting that mobile platforms don’t even support positive rates other that 1. I'm pretty sure mobile Firefox supports non-1 playback rates. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
[whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In head)
Bueller...? Bueller...? This request is almost 5 years old now, but it is even more relevant today, now that web developers are increasingly embracing SVG for purposes of responsive design and accommodating HiDPI displays. Putting SVG defs and other metadata-related elements in HTML's head seems like an obvious choice from a semantic standpoint. But it is currently illegal in the HTML spec because SVG does not distinguish between embedded and metadata content models for its elements, which Hixie has requested so that the HTML spec can simply point to the SVG spec's definitions. (Please see quoted text.) Again, is this something the SVG WG is willing to do? Thank you, Hugh On Thu, Dec 22, 2011 at 7:28 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Cameron McCormack forwarded this proposal to public-svg-wg a year ago (thanks, Cameron!) but no one commented on it, so I'm reposting it here. Is this something the SVG WG is willing to do? Thanks! -Hugh -- Forwarded message -- From: Ian Hickson i...@hixie.ch Date: Mon, Dec 6, 2010 at 9:35 PM Subject: Re: [whatwg] Allow Select SVG Elements In head To: Hugh Guiney hugh.gui...@gmail.com Cc: whatwg wha...@whatwg.org On Fri, 27 Aug 2010, Hugh Guiney wrote: I'm authoring an XHTML host document with namespaced inline SVG and XLink. I have vector images that recur throughout the site. I'd like to implement SVG's defs and use to reduce the file size of the document and keep style separate from content, as with CSS. If I put an SVG tree with defs anywhere in the XHTML document, other trees with use xlink:href will correctly reference it, as tested in the latest public release Gecko, Webkit, and Opera. So the question becomes, where do I put it? The most obvious answer seems to be head, since, like CSS definitions, this is metadata being defined for use elsewhere in the document. The only problem is, Validator.nu doesn't like it: Error: SVG element svg not allowed as child of XHTML element head in this context. (Suppressing further errors from this subtree.) Same error when ditching the root svg and including only defs, the result of which still works in all but Opera. This error can be avoided if the defs tree is put in the XHTML body, but then there is blank space the size of the defined shapes at the top of the document in all 3 engines. A workaround is to give svg a @width and @height both of 0. But leaving the definitions in the body when they technically don't represent contextual content strikes me as non-semantic. My proposition would be to simply spec a subset of SVG consisting only of metadata elements as valid in HTML's head context. This could be just defs—I'm unsure if there are any other elements that fit this definition since I am relatively new to SVG; but in either case it'd aid semantics and is already supported in today's SVG-capable browsers. This is an interesting idea. I would recommend approaching the SVG working group and suggesting that they define the content model of svg and other SVG elements such that there's two ways to use it: one where svg is considered embedded content, and one where it's considered metadata content, with appropriate restrictions on the latter. With such a set of definitions in place, the HTML spec's model would just work (it already refers to the content model of head as just metadata content, for instance). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] FW: VIDEO and pitchAdjustment
From: Domenic Denicola From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen in Firefox in the forseeable future. I was looking in to this yesterday and it seems like the spec places absolute no limits on playbackRate. Am I right? This seems a bit bad. If nobody is supporting negative nor has any plans to, we should at least consider throwing for negative. I guess we can leave the upper limit unspecified, unless implementations all happen to agree on one. Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my testing. Firefox, Chrome and Safari on desktop and mobile don’t support negative values at all AFAICT. I have notes here suggesting that mobile platforms don’t even support positive rates other that 1. -- James Ross ja...@james-ross.co.uk
Re: [whatwg] VIDEO and pitchAdjustment
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen in Firefox in the forseeable future. I was looking in to this yesterday and it seems like the spec places absolute no limits on playbackRate. Am I right? This seems a bit bad. If nobody is supporting negative nor has any plans to, we should at least consider throwing for negative. I guess we can leave the upper limit unspecified, unless implementations all happen to agree on one.
Re: [whatwg] VIDEO and pitchAdjustment
On Fri, Aug 28, 2015 at 12:17 PM, Domenic Denicola d...@domenic.me wrote: From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen in Firefox in the forseeable future. I was looking in to this yesterday and it seems like the spec places absolute no limits on playbackRate. Am I right? This seems a bit bad. If nobody is supporting negative nor has any plans to, we should at least consider throwing for negative. I guess we can leave the upper limit unspecified, unless implementations all happen to agree on one. playbackRate should also probably be set to 0 when the video is paused, seeing as they accomplish the same task. Or better yet redefine pause() to be setting playbackRate to 0. You would of course then have to keep a note of what the playbackRate was before pause() was called, but it would fix the issue of playbackRate being set to zero, yet video.paused returning false. So video.pause() would save the current playbackRate and then set playbackRate to 0, and video.play() would restore the playbackRate saved by pause(). video.paused could then just return (playbackRate ? false : true).
Re: [whatwg] VIDEO and pitchAdjustment
On Sat, Aug 29, 2015 at 8:27 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Aug 29, 2015 at 8:18 AM, James Ross ja...@james-ross.co.uk wrote: Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my testing. That's not so hard to implement, but it's also mostly useless since keyframes are often several seconds apart or more. It could be useful for a few usecases like fast-backward. Windows Media Player does it this way. FWIW, QuickTime supports per-frame backward playback if you press and hold the left arrow. I guess they cannot guarantee the rate, which makes them require holding the key instead of providing a playback rate setting. - Xidorn
