Re: figure role backgrounds

Hi, folks–

Both Anne and Amelia made assertions about the plans, goals, and desires 
of the SVG WG. I don't think it's accurate to pigeonhole the SVG WG this 
way, because there are differing opinions in the group.

I, for one, would love to see arbitrary HTML elements allowed in SVG, 
especially structured-text elements like lists and headings. I know 
there are potential parser problems with it, but I wonder if those can't 
be solved.

At the same time, I don't think it should always be necessary to use 
HTML for a simple bit of semantic functionality like a figure. There are 
plenty of non-browser environments that use SVG, like authoring tools, 
which might choke on the inclusion of arbitrary HTML (not every SVG tool 
should also have to be a conforming HTML user agent).

The issue of whether there is a 'figure' role seems pretty minor to me, 
and not worth getting worked up about.

Regards–
Doug

On 9/14/16 5:42 PM, Amelia Bellamy-Royds wrote:
> To clarify:
>
> SVG does not, and has no plans to, allow arbitrary semantic HTML content
> inside SVG files.  There are only three valid ways to use HTML inside SVG:
>
>   * In a user agent that supports HTML, an SVG `<foreignObject>` allows
>     you to inject a container of CSS-styled HTML content.  However, this
>     affects much more than just semantics.  Theoretically, you can have
>     another inline SVG inside that HTML, but the layout would be quite
>     different than without the foreign object markup.  Furthermore, it
>     has no effect in SVG user agents that don't support HTML.
>
>   * To improve fallback in browsers that don't support SVG, the SVG
>     metadata elements (title, desc, and metadata) allow
>     foreign-namespace content, including HTML markup.  These have
>     neither visual nor semantic effect on the SVG document.
>
>   * SVG 2 allows a limited set of HTML embedded-content elements to be
>     used in SVG: canvas, video, audio, and iframe.  This is not yet
>     supported in browsers or the HTML parser.
>
>
> Creating ARIA roles which are directly paired with HTML semantic
> elements seems to me like the definition of avoiding duplication of
> efforts.  Instead of creating a new semantic language, we would be
> making the existing HTML semantics available as annotations to any XML
> document.  In addition to SVG, this could be relevant in other languages
> where the markup describes layout rather than semantics, such as XSL-FO.
>
>
> On 14 September 2016 at 02:45, Anne van Kesteren <annevk@annevk.nl
> <mailto:annevk@annevk.nl>> wrote:
>
>     > The SVG accessibility effort does not want to piece part chunks of host language elements in the middle of an SVG document which needs to stand alone. Not all SVG documents are embedded in HTML. So, sticking an HTML figure element inside of an SVG document is a non-starter.
>
>     This seems diametrically opposed to the efforts of the SVG WG, who no
>     longer wish to duplicate HTML efforts and are working on making it
>     easier to use both together. I don't understand why the SVG
>     accessibility effort would chose a different direction from the SVG
>     WG.
>
>
> On 14 September 2016 at 14:14, Alexander
> Surkov <surkov.alexander@gmail.com
> <mailto:surkov.alexander@gmail.com>> wrote:
>
>
>     I buy the argument that you may need HTML figure semantics in SVG,
>     I'm not yet sure that ARIA has to be extended to address it, because
>     HTML already has <figure> and it can be reused in SVG document. See
>     Anne's answer on this thread [1].
>
>
>

Received on Wednesday, 14 September 2016 22:57:31 UTC