[Bug 8404] Refocus the figure element back to being a figure

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404





--- Comment #31 from Shelley Powers <shelleyp@burningbird.net>  2009-12-01 00:42:06 ---
(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #24)
> > > (In reply to comment #19)
> > > 
> > > > 
> > > > Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> > > > 
> > > > The data is not accessible as a table.
> > > > 
> > > > If you all want to include JPEGs of tables in img elements, that's cool. You
> > > > can put anything you want into an image file.
> > > 
> > > I think it would be a terrible message to send if we tell HTML authors that the
> > > only way to include text or tabular data in a figure is to turn it into an
> > > image. Text on the Web should be marked up as text whenever possible, even if
> > > it is serving a largely graphical purpose. Ditto for tabular data. Turning text
> > > or tables into images is bad for accessibility, indexability, find-in-page
> > > features, copy/paste. It's an anti-pattern. If restricting <figure> would have
> > > this effect on HTML authoring then we absolutely should not do it.
> > > 
> > 
> > Another option is to add one more element:
> > 
> > iframe
> 
> That introduces some serious downsides:
> 
> 1) Extra network request to load the contents of the <iframe>
> 2) Extra memory/performance overhead per <iframe> (likely to become very
> expensive if a document has many figures using this trick.
> 3) Requires the embedder to determine a fixed size, rather than allowing
> natural sizing of the figure. (This will go away when/if browsers implement
> seamless iframes; so far none has).
> 4) <iframe>s do not work as well as smoothly as in-flow content in many
> existing assistive technologies.
> 
> > 
> > Then we could define whatever HTML in a separate HTML file, and include it in
> > figure using iframe.
> > 
> > This would allow svg, mathml, img, iframe, object, and video as figure
> > contents. 
> 
> I would ask: what semantic benefit is there if <figure> can't contain a table
> or a code sample, but it can contain an <iframe> containing a table or a code
> sample? It seems like this doesn't really restrict what <figure> can contain,
> just restricts the mechanism in an arbitrary and inconvenient way.
> 


I wasn't happy with the use of iframe either. It was another idea.

Frankly, I'm thinking the best thing to do is to remove figure. It is too
general to be useful semantically, and people will be confused when figures are
used for material that is not graphical or an illustration. And there's nothing
in the definition of figure that prevents non-illustrative material. 

You referenced Docbook earlier, but the definition for figure in Docbook is for
illustrative purposes. If we don't restrict the elements to those compatible
with illustrative purposes, then figure will be misused. People probably won't
know when to use aside, and when to use figure. 

Or they won't care, of they'll just use div elements.

Shelley


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 1 December 2009 00:42:15 UTC