Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
On Sun, 22 Mar 2015 15:06:40 +0100, Martin Janecke whatwg@prlbr.com wrote: I've done a few tests and provide links to them below the following discussion. ... Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 5 is the proper way to do this IMHO. A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. Test 6: https://prlbr.de/2015/03/html-img-with-svg.html Here I've referenced the SVG (as defined in test 5) with an img element instead of including it inline. This doesn't work in any browser. Except for IE9 the browsers don't even show the included photograph. IE9 shows the photograph, but neither links nor tooltips work. Due to privacy security concerns, an svg will not fetch any external content when it is referenced by an img element. ... However, the HTML living standard features the picture element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors (https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element). The SVG solution discussed above references the image by a different SVG mechanism. Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:21:08 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( -Boris There are a couple of events in SVG which seem to be in conflict with the reflection pattern. The events with names: endEvent, beginEvent and repeatEvent [1]. The attributes that correspond to these are onend, onbegin and onrepeat respectively. Due to how the event-value syntax[2] works in SVG animation elements the event names can't be changed without conflicting with the sync-base value syntax[3]. I wish the event names were consistent with the pattern used for event handler content attributes, but they're not. In SVG2 most of the events with SVG event name prefixes have been removed[4], e.g SVGLoad is now a plain load, which means they follow the pattern for event handler content attributes. SVGResize, SVGScroll and SVGZoom still remain to be fixed in the spec. Of these only SVGZoom lacks an existing unprefixed counterpart, so that would be a possible addition to GlobalEventHandlers with the event name zoom. My question is: what should be done with the SVG specific event handlers? Should they be added to GlobalEventHandlers, or should they be just on SVGElement? This was ACTION-3542 (SVG WG). [1] http://www.w3.org/TR/SVG11/interact.html#BeginEvent [2] http://www.w3.org/TR/SVG11/animate.html#EventValueSyntax [3] http://www.w3.org/TR/SVG11/animate.html#SyncbaseValueSyntax [4] https://svgwg.org/svg2-draft/interact.html#SVGEvents -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Specify getSVGDocument
SVG 1.1 Second Edition deprecated .getSVGDocument(), and made it an alias for .contentDocument essentially yes. SVG2 has not yet seen any edits related to this method. But it's not unlikely that SVG2 will drop it given that SVG 1.1 states: This interface is deprecated and may be dropped from future versions of the SVG specification. It's possible that .getSVGDocument() is still in use due to embed elements not supporting .contentDocument, and people wanting to allow the use of plugins for svg content in case there was no native svg support in the browser. This may have changed due to the Adobe SVG plugin not being supported anymore. An example: http://xn--dahlstrm-t4a.net/svg/html/get-embedded-svg-document-script.html /ed On Tue, Nov 19, 2013 at 5:33 AM, Philip Jägenstedt phil...@opera.comwrote: On Mon, Nov 18, 2013 at 8:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/18/13 1:37 PM, Philip Jägenstedt wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643 In my testing, getSVGDocument is supported on embed, frame, iframe and object in Firefox Nightly, IE11 Preview, Safari 7.0 and Opera 12.16, the only exception being frame.getSVGDocument in Firefox. I don't know if this API is actually useful, but since it's already implemented everywhere it should probably be spec'd. SVG2 is trying to spec it, afaict, as basically an alias for .contentDocument. It _would_ make more sense to do that in HTML, I agree. Indeed, since it's actually on the HTML*Element interfaces. SVG2 can do partial interfaces, of course, but that makes it a bit harder to actually find. Philip
