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 2:26 PM, Matthew Raymond wrote:
Alexey Feldgendler wrote:
...
In your opinion, if %Text attributes (title, alt) in HTML allowed
nested markup somehow, wouldn't the title attribute sufficient for
fulfilling the use case of captions?
No, because a caption is not
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
Le 28 nov. 2006 à 9:34, David Walbert a écrit :
In principle, I see your point, but I don't see that such broadly
defined figures would have widespread practical value. A figure
in print publishing traditionally referred to anything that
couldn't be normally typeset, but in practice that
Le 28 nov. 2006 à 11:09, James Graham a écrit :
Broad semantics mean that UAs can do fewer useful things with the
information. That dilutes the value of having any semantics at all.
Paragraphs are used for so many thing they can hardly be used to
extract any information at all, yet they're
In response to a weblog post of mine[1], Ian stated[2]:
we can’t make trailing “/” characters meaningful — it would
change how about 49% of the Web is parsed
Just to make sure that we are talking about the same thing, let me make
a much more carefully scoped proposal.
In HTML5, there
Hello,
Over on the IETF Atom Syntax mailing list we're discussing whether or
not to pursue the autodiscovery draft that had previously been put on
the table [1] or to simply point to the HTML5 work and be done with it.
While reviewing the HTML5 draft and comparing that to the Atom
auto-discovery
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
2. Are multiple alternate links with the same type attribute
considered to be equivalent regardless of where those links appear
in the document.
What do you mean by equivalent ?
--
Robert Sayre
Michel Fortin wrote:
Le 28 nov. 2006 à 11:09, James Graham a écrit :
Broad semantics mean that UAs can do fewer useful things with the
information. That dilutes the value of having any semantics at all.
Paragraphs are used for so many thing they can hardly be used to extract
any information
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
On Tue, 28 Nov 2006, James M Snell wrote:
Ian Hickson wrote:
[snip]
1. Is the order of alternate link rels in a document significant?
Good question. The draft hadn't covered that. I've now fixed the spec
to say that the order is important in one respect: the first link,
a, or
On Nov 28, 2006, at 2:41 PM, Michel Fortin wrote:
The example from mozilla.org doesn't require any special container
element, because it needs no caption. The set-aside text is an
example of what's being discussed in the surrounding text, and the
heading example serves perfectly well to
14 matches
Mail list logo
