On Sat, 4 Nov 2006, Matthew Paul Thomas wrote:
or make the association implicit by using the for attribute
embed id=funnyVid ...
caption for=funnyVidA funny video of a man being hit in the groin by a
football/caption
That would work for the current page layouts of YouTube and
On Nov 27, 2006, at 8:49 PM, Ian Hickson wrote:
figure
img ...
legend ... /legend
/figure
Ian, thank you -- this is simple, clear, and functional. Ideally (as
several people have pointed out) the element would be called
caption, but I'm content to accept your explanation
On Tue, 2006-11-28 at 09:16 -0500, David Walbert wrote:
Would the credit element, whatever it is called, be block or inline?
Semantically I don't believe it makes much difference. I suppose I'd
recommend that it be an inline element inside the legend, because
then with CSS I could declare it
On Nov 28, 2006, at 9:38 AM, Benjamin Hawkes-Lewis wrote:
address / is not the same as credit / but you might well want to
include an address / (e.g. for a link to the creator's homepage) in
credit / which might necessitate a block content model.
Good point.
Finally, the captions for
On Tue, 2006-11-28 at 15:56 -0500, Jeff Seager wrote:
I think the artist's name and copyright notice are worthy advisory
information to be included in the TITLE attribute of img, embed, or
object, and this has been possible for some time.
We're dealing with a hypertext medium. Attributes
Based on a lot of the feedback, I wrote up a first draft of how to do
image captions in HTML5:
figure
img ...
legend ... /legend
/figure
It's a block-level element, same level as p. The image and the legend
can come in any order, but there must be exactly one of each. The
Le 27 nov. 2006 à 20:49, Ian Hickson a écrit :
On Wed, 1 Nov 2006, Michel Fortin wrote:
I see no reason to be restrictive on the kind of content that can be
captioned.
Well, we want the semantics to be well-defined. It's not clear to
me what
the semantics will be in all cases if we allow
On Thu, 6 Apr 2006, mozer wrote:
Proposition 1 :
-
And what about just giving to img a content ?
This, sadly, wouldn't be very backwards compatible.
So why not to provide brand new element, say, x-img / that
have closed model? The same apply to x-input / and few others
I've chosen an inline-level content model because it allows not only
img, but also structured inline-level elements like pre. I'm not so
sure about that choice however.
Hm, pre seems like an interesting thing to put in a figure[...] I
certainly could see us also allowing figure to label
Michel Fortin wrote:
To me, a figure contains illustrative content attached to a document. It
may be an image, a code sample, or a snippet of another document used as
an example. I think it's important we do not try to narrow too much what
can and what cannot be contained in a figure; that's
On Tue, 2006-11-28 at 01:15 -0500, fantasai wrote:
I'd suggest using address, e.g.
figure
img
addressPhoto by Mariel/address
/figure
figure
img
captionCarcassonne/caption
addressPhoto by Mariel/address
/figure
Mere attribution is not contact
11 matches
Mail list logo
