Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Thu, 23 Nov 2006, Alexey Feldgendler wrote: On Wed, 22 Nov 2006 23:52:41 +0600, Steve Runyon [EMAIL PROTECTED] wrote: One minor point I would clarify: Alexey, you stated that label for=XX type=title would replace the title attribute. I assume you meant that it should *supplement* it, since you wouldn't want to preclude its use or mess with backward compatibility. It would replace the title attribute from the semantic POV only. For example, various semantic extractors which know about label type=title should use its content instead of the title attribute when they need to know the title of something. For those which don't yet know about label type=title, the title attribute will provide reasonable fallback. On Thu, 23 Nov 2006, Alexey Feldgendler wrote: On Thu, 23 Nov 2006 01:28:13 +0600, Michel Fortin [EMAIL PROTECTED] wrote: I'm not saying it's a caption either. A caption is just one of the possible ways of rendering a title. But is a caption limited to a title? Very often, captions contains some explanations too. I just opened a computer architecture book near me I knew was full of figures and the first figure I spotted had a eleven-line caption -- 5 complete sentences. Anyway, caption is presentational. The semantic relation of that text to the figure, if it's not a title, is most probably description or explanation. It's another problem how to express this relation. Probably a generic form of label for=... without type attribute should be used -- something like a div without specifying any finer semantic role. I know not everyone use captions like this. But calling captions title pose two problems: it clashes in name with the title attribute, making both of them a little more ambiguous, It's intended that they share the name. The content of label type=title *means* the same as the value of title attribute. The same goes for label type=alt vs. alt attribute. I think the figure element handles all of the above now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Dave writes: To an indexing service, the caption is the single most important thing about an image. By separating the caption from the IMG element, you force the search engine to apply a heuristic of some variety to infer the connection ... The indexing service user agent has to make sense of all of this, in order to figure out what caption goes with what image, and it is just going to be extremely difficult to get that with no actual structural relationship between the caption and the image. Well said, Dave! I think this is an understanding that has been (mostly) missing in this discussion. We need a structural and semantic link between caption and image, first and foremost. There will inevitably be all kinds of implementations of this to suit an equal number of purposes, but this is a core need to be met in any future iterations of HTML/XHTML. Without a consistent structural and semantic expression of whatever we call this caption, the cognitive link between image and caption will be haphazard, at best -- in user agents and in the end user (the audience). Thank you also, Dave, for reminding us that web browsers aren't our only targets. As most of us are probably focused on GUI browsers most of the time, the needs of other media can be swept aside too easily. But they must be considered in the final specifications, so we need to bear them in mind now. Where to go from here? Title as currently specified won't do the job for captions because, as Matthew Raymond points out, a caption is not necessarily 'advisory information'[1], which is what the |title| attribute is defined as containing. But would there be support for broadening the definition of title and encouraging its adoption for image captioning? It seems to me that there would be advantages to piggybacking our purpose on an element or attribute already specified, implementing an evolutionary change as opposed to a revolutionary one. So please consider this: What do we lose, semantically or cognitively, even if we entirely discard the advisory information capabilities in the title attribute? It seems to me we'd lose far less than we may gain in having a proper structure for captions. Existing titles may not inform as well as a proper caption, but would probably not be rendered meaningless as such. The ultimate solution should be as simple and direct as possible, I think. I'm just tossing this out for further consideration. I'm also mindful of the previous arguments in favor of allowing markup within captions, which suggests that the caption ought to be an element rather than an attribute. I guess that would be nice, but I'm not sure I agree with the necessity of it. Form follows function, and all that. Jeff Seager
Re: [whatwg] The IMG element, proposing a CAPTION attribute
HTML is made up of 5 atoms: div span col tr td The web browser converts the img element into: div style='content:url(image)'/div Conversely, if you add a caption, it has to generate this: div div style='content:url(image)'/div div style='_$caption'caption/div /div Needless to say, its really just setting some attributes or properties, maybe a bitmask or two to indicate the atom, or if it is a more modern implementation, it might be attaching some function pointers (delegates) to handle the behavior of the atom. To the web browser the caption is, indeed, presentational, as a result. If the HTML standard only had to deal with web browsers, if it only had to worry about what Gecko and Opera want, the story would end there. However, the web browser is not the only user-agent. Web browsers don't care about structural versus presentational markup. They care about structure precisely to the point that it triggers CSS rules, and no farther than that. Some might infer things based on errors in the tagsoup. (and most people in the list probably don't remember what the web was like with gopher and the first generation of HTTP browsers, where a markup error would actually crash the browser -- and sometimes the host OS along with it) Indexing services, on the other hand, care only about the relationships between data. They want to form cross reference tables that they can use to implement features such as search engines. To an indexing service, the caption is the single most important thing about an image. By separating the caption from the IMG element, you force the search engine to apply a heuristic of some variety to infer the connection. Consider a page of thumbnails with captions, for example, being indexed by Google. Google needs to know what caption belongs to what thumbnail. This is trivial if caption is an attribute, child element or has an IDREF association with the image. In any other scenario, the markup that has to be handled is diverse. I mean, the images could be floated divs with the caption in the div. They could be td elements, with a separate td element in the next row for the caption, they could be position:absolute with another position:absolute element somewhere else in the document positioned where some GUI tool put it. The indexing service user agent has to make sense of all of this, in order to figure out what caption goes with what image, and it is just going to be extremely difficult to get that with no actual structural relationship between the caption and the image. I don't think it matters if it is an attribute, a child element, or a separate element associated via an IDREF, but one of those things must happen in order to maintain the structural relationship, so that an indexing service can leverage that to provide better cross references, and ultimately better search engine results. - Original Message - From: Michel Fortin [EMAIL PROTECTED] To: Alexey Feldgendler [EMAIL PROTECTED] Cc: WHATWG List [EMAIL PROTECTED] Sent: Thursday, November 23, 2006 7:43 AM Subject: Re: [whatwg] The IMG element, proposing a CAPTION attribute Le 23 nov. 2006 à 3:32, Alexey Feldgendler a écrit : Anyway, caption is presentational. Oh, please. If caption is presentational, then paragraph and table are as much, if not more. According to my dictionary: paragraph a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. table a set of facts or figures systematically displayed, esp. in columns. caption a title or brief explanation appended to an article, illustration, cartoon, or poster. If there is a definition in this list which doesn't suggest some kind of visual presentation, it's the caption. Surely you have a different definition than me. The semantic relation between a caption and its image, or figure, should be exactly what is defined above: a title or a brief explanation. (Definitions from the New Oxford American Dictionary, 2nd edition) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey Feldgendler wrote: On Fri, 24 Nov 2006 09:11:28 +0600, Matthew Raymond I think we have two separate issues here. You're trying to address a valid concern, but it has nothing to do with figures and figure captions, and there's no reason to avoid markup for figures just because we want to address the limitations of attributes like |title| and |alt|. 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 necessarily advisory information[1], which is what the |title| attribute is defined as containing. [1] http://www.w3.org/TR/html4/struct/global.html#adef-title
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Fri, 24 Nov 2006 09:11:28 +0600, Matthew Raymond [EMAIL PROTECTED] wrote: Second, it contains the word figure, but I think this can be more generic and work for other elements which have %Text attributes. I think we have two separate issues here. You're trying to address a valid concern, but it has nothing to do with figures and figure captions, and there's no reason to avoid markup for figures just because we want to address the limitations of attributes like |title| and |alt|. 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? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Thu, 23 Nov 2006 18:43:45 +0600, Michel Fortin [EMAIL PROTECTED] wrote: caption a title or brief explanation appended to an article, illustration, cartoon, or poster. If there is a definition in this list which doesn't suggest some kind of visual presentation, it's the caption. Surely you have a different definition than me. I was thinking about a caption as text displayed above/below the figure. In this sense, it's presentational. However, the definition above is semantic. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 23:52:41 +0600, Steve Runyon [EMAIL PROTECTED] wrote: One minor point I would clarify: Alexey, you stated that label for=XX type=title would replace the title attribute. I assume you meant that it should *supplement* it, since you wouldn't want to preclude its use or mess with backward compatibility. It would replace the title attribute from the semantic POV only. For example, various semantic extractors which know about label type=title should use its content instead of the title attribute when they need to know the title of something. For those which don't yet know about label type=title, the title attribute will provide reasonable fallback. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Thu, 23 Nov 2006 03:27:31 +0600, Henri Sivonen [EMAIL PROTECTED] wrote: label for=fig1 type=title.../label label is not good, because it is reasonable to style form control labels the way the platform styles labels, but the styling may not be appropriate for figure captions. Also, the for attribute is now supposed to refer to a form control. I agree that reusing label can cause problems, so I'd like to find a brand new name, too. I think it is better to introduce a figcaption or something than to confuse what label is. I don't like figcaption for two reasons. First, it contains the word caption while I propose using the new element in title, alt, and label roles at least. Second, it contains the word figure, but I think this can be more generic and work for other elements which have %Text attributes. Maybe title-text, alt-text and label-text for each of the three purposes? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 23 nov. 2006 à 3:32, Alexey Feldgendler a écrit : Anyway, caption is presentational. Oh, please. If caption is presentational, then paragraph and table are as much, if not more. According to my dictionary: paragraph a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. table a set of facts or figures systematically displayed, esp. in columns. caption a title or brief explanation appended to an article, illustration, cartoon, or poster. If there is a definition in this list which doesn't suggest some kind of visual presentation, it's the caption. Surely you have a different definition than me. The semantic relation between a caption and its image, or figure, should be exactly what is defined above: a title or a brief explanation. (Definitions from the New Oxford American Dictionary, 2nd edition) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey Feldgendler wrote: On Thu, 23 Nov 2006 03:27:31 +0600, Henri Sivonen [EMAIL PROTECTED] wrote: label for=fig1 type=title.../label label is not good, because it is reasonable to style form control labels the way the platform styles labels, but the styling may not be appropriate for figure captions. Also, the for attribute is now supposed to refer to a form control. I agree that reusing label can cause problems, so I'd like to find a brand new name, too. Agreed, since a label and a caption are not semantically equivalent. I think it is better to introduce a figcaption or something than to confuse what label is. I don't like figcaption for two reasons. First, it contains the word caption while I propose using the new element in title, alt, and label roles at least. I don't see a figure caption as being semantically the same as any of these. Also, a caption might refer to or describe multiple images. Second, it contains the word figure, but I think this can be more generic and work for other elements which have %Text attributes. I think we have two separate issues here. You're trying to address a valid concern, but it has nothing to do with figures and figure captions, and there's no reason to avoid markup for figures just because we want to address the limitations of attributes like |title| and |alt|. Maybe title-text, [...] The |title| attribute is supposed to provide advisory information, so why not advisory or adv? [...] alt-text [...] Huh? Why not just alternate or alt??? | img id=blah [...]alt for=blahcontent/alt This could be combined with the |data| attribute for better fallback: | img id=blah [...] alt=simple content | alt for=blah data=AltContent.xhtml/alt and label-text for each of the three purposes? The only thing that you'd use label-text for is optgroup, since |label| for option is supposed to be a shorter form of the contents of the element. I don't think that group names for option elements is a sufficient use case to justify this element.
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Tue, 21 Nov 2006 10:30:17 +0600, Matthew Raymond [EMAIL PROTECTED] wrote:
There are W3C guidelines that say that UI in user agents should
follow the UI conventions of the underlying operating system. This is
what caused the demise of general focus passing for label elements
(which was specified in HTML 4.01). As of WF2, label elements only
pass focus if labels would normally have focus passing for that kind of
control in the user's OS. (I called it an irrational consistency, but
I was overruled.)
Let's not think of label with type attribute or any other element which is
introduced instead as of a visually element. It should be just a way of
expressing the value of title, alt etc with rich markup inside.
I don't necessarily have a problem with supporting rich tooltips, but
my main concern is that there isn't much of a use case for it, it won't
match UI conventions for most platforms, and fallback is a nightmare.
Looking at the number of JS libraries implementing tooltips with rich markup,
I can say there's plenty of a use case.
With regard to fallback, think of how your above example would render
if the CSS file failed to load or wasn't supported. It would probably be
something like this:
Here is a backward compatible example of markup:
label[type=title] { display: none; display: tooltip }
img id=img1 src=... title=My lovely kitten
label for=img1 type=titleMy stronglovely/strong kitten/label
1. Today's UAs will ignore display: tooltip and apply display: none to the
label element.
2. Future UAs will honor display: tooltip, and the content of the label
element will be shown in a tooltip for the image, overriding the tooltip which
would be shown otherwise (the value of the title attribute).
3. Semantically, the title of image is considered to be My
stronglovely/strong kitten -- with rich markup inside.
For various popup purposes I have added popup element that is
display:none normally and has better semantic meaning so
we use popups for such tooltips in almost all cases.
I believe that popup would be as presentational as center. The semantics of
my proposed markup is that the fragment of rich text within label is
considered the title, alternative representation, etc of the referenced
element, overriding the corresponding attribute of that element. The rule that
label type=title should be displayed as a tooltip should be expressed by a
stylesheet.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 5:56, Alexey Feldgendler a écrit : Let's not think of label with type attribute or any other element which is introduced instead as of a visually element. It should be just a way of expressing the value of title, alt etc with rich markup inside. There is already a way to express tooltips in HTML. Yeah, it's rather limited. I'm not against new CSS properties to display things as tooltips, but I'd rather see that confined to custom stylesheets. And reusing label, or even introducing a new element, to override attributes (especially arbitrary attributes) seems cumbersome to me... how do you represent that in the DOM? It is also my opinion that the title attribute, whether it allows rich markup or not, is not the right place for a caption. I'm certainly not going to use it if browsers hide captions in tooltips in their default stylesheets. The default stylesheet needs to be a reasonable fallback, and an image caption must be visible while glancing at the page. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 20:02:39 +0600, Michel Fortin [EMAIL PROTECTED] wrote:
Let's not think of label with type attribute or any other
element which is introduced instead as of a visually element. It
should be just a way of expressing the value of title, alt etc
with rich markup inside.
There is already a way to express tooltips in HTML. Yeah, it's rather
limited.
HTML is not about expressing tooltips. HTML is about expressing image titles.
And yes, the HTML way of expressing image titles is rather limited.
I'm not against new CSS properties to display things as tooltips, but I'd
rather see that confined to custom stylesheets.
Whether the rules like label[type=title] { display: tooltip } make it to the
default stylesheet or not is a separate question. I'd rather say not.
And reusing label, or even introducing a new element, to override
attributes (especially arbitrary attributes) seems cumbersome to
me... how do you represent that in the DOM?
It's not about overriding attributes in DOM. The markup I've shown will be
represented in DOM exactly as it's spelled.
What is indeed overriden is the title of the image, in the semantical sense.
Google Images, for example, would use the content of label type=title
instead of the title attribute.
It is also my opinion that the title attribute, whether it allows
rich markup or not, is not the right place for a caption. I'm
certainly not going to use it if browsers hide captions in tooltips
in their default stylesheets. The default stylesheet needs to be a
reasonable fallback, and an image caption must be visible while
glancing at the page.
I think the default stylesheet should not be different from what browsers
currently have: label is shown, and it doesn't appear as a tooltip.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 20:42:11 +0600, Michel Fortin [EMAIL PROTECTED] wrote:
So I propose a new fcaption elements -- for figure caption -- in
replacement for the caption element in my previous figure construct:
figure
fcaptionCaption Text/fcaption
img src=...
/figure
And if I were to propose a default styling for this, it'd be this one:
figure { display: table; }
fcaption { display: table-caption; }
figure cannot be used like this:
table
thead
tr
thPainting/th
thTitle/th
thAuthor/th
/tr
/thead
tbody
tr
tdimg id=img1 src=.../td
tdlabel for=img1 type=titleMona Lisa/label/td
tdLeonardo da Vinci/td
/tr
...
/tbody
/table
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 9:53, Alexey Feldgendler a écrit :
On Wed, 22 Nov 2006 20:42:11 +0600, Michel Fortin
[EMAIL PROTECTED] wrote:
So I propose a new fcaption elements -- for figure caption -- in
replacement for the caption element in my previous figure
construct:
figure
fcaptionCaption Text/fcaption
img src=...
/figure
And if I were to propose a default styling for this, it'd be this
one:
figure { display: table; }
fcaption { display: table-caption; }
figure cannot be used like this:
[...]
Indeed, figure markup cannot express a full table -- but it doesn't
need to. Following CSS 2.1 [1], anonymous boxes are created for rows
and cells wherever appropriate. In the previous example, an anonymous
row and an anonymous cell are created to hold the content of the
figure. The figure effectively behave visually as a one-cell table
with a caption.
[1]: http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
It works pretty well in browsers that implement `display: table`. And
a not-so-bad fallback for browsers that do not implement the CSS
table display model (IE) is to display both figure and fcaption
as blocks, setting the width explicitly for floated figures (so that
the caption does not extend the box horizontally).
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 9:53, Alexey Feldgendler a écrit : figure cannot be used like this: table thead tr thPainting/th thTitle/th thAuthor/th /tr /thead tbody tr tdimg id=img1 src=.../td tdlabel for=img1 type=titleMona Lisa/label/td tdLeonardo da Vinci/td /tr ... /tbody /table Hum, now that I see your example again, I understand that I haven't adressed at all what you meant. Well, indeed that's a limitation of figure: it can't span across different table cells. But on the other side, I don't think I'd call Mona Lisa a caption in your example. It's certainly a title however, and I think the table makes the association pretty clear by itself. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 21:34:05 +0600, Michel Fortin [EMAIL PROTECTED] wrote: figure cannot be used like this: table thead tr thPainting/th thTitle/th thAuthor/th /tr /thead tbody tr tdimg id=img1 src=.../td tdlabel for=img1 type=titleMona Lisa/label/td tdLeonardo da Vinci/td /tr ... /tbody /table Hum, now that I see your example again, I understand that I haven't adressed at all what you meant. Well, indeed that's a limitation of figure: it can't span across different table cells. But on the other side, I don't think I'd call Mona Lisa a caption in your example. It's certainly a title however, I'm not saying it's a caption either. A caption is just one of the possible ways of rendering a title. and I think the table makes the association pretty clear by itself. It's not clear for Google Images which needs to extract (image, title) pairs from documents. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 22 Nov 2006 21:32:35 +0600, James Graham [EMAIL PROTECTED] wrote: In general I think that having img and imgcaption (or whatever they are called) enclosed by a single element is a better idea since the increased simplicity makes rendering easier. For example, how would you expect a browser to render this?: pFoo img id=bar pFoobar pBaz imgcaption for=barPictures are nice!/imgcaption In all current UAs I guess it would render something like: Foo img Foobar Baz Pictures are nice This is exactly how I expect the above markup to be rendered. Unless the imgcaption is taken out of the flow by specifying display:tooltip, it should show where it's written. In fact, the difference between imgcaption and div is no more than between address and div: imgcaption is technically the same as div but conveys semantical meaning that its content is a title for image #bar. But I can't think of many situations where a figure's caption should be separate from the figure itself and, from the discussion above, it seems that some people would expect: Foo img Pictures are nice Foobar Baz No, I don't expect this. If the author wanted this, he would have written imgcaption right after img. Another issue to consider is the possibility of multiple images with a single caption (this is very common in scientific papers, print magazines, etc.). A construct like figure img img img imgcaption /figure might be enough to support this (the details are, I think, non-trivial); something that requires the caption to point to exactly one image cannot. I'm thinking of label type=title as of just a fancy replacement for the title attribute. In your example, I would write: div id=fig1 img img img /div label for=fig1 type=title.../label ...probably using something more specific than div to group the img elements. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey Feldgendler wrote:
On Wed, 22 Nov 2006 20:42:11 +0600, Michel Fortin [EMAIL PROTECTED] wrote:
So I propose a new fcaption elements -- for figure caption -- in
replacement for the caption element in my previous figure construct:
figure
fcaptionCaption Text/fcaption
img src=...
/figure
And if I were to propose a default styling for this, it'd be this one:
figure { display: table; }
fcaption { display: table-caption; }
figure cannot be used like this:
table
thead
tr
thPainting/th
thTitle/th
thAuthor/th
/tr
/thead
tbody
tr
tdimg id=img1 src=.../td
tdlabel for=img1 type=titleMona Lisa/label/td
tdLeonardo da Vinci/td
/tr
...
/tbody
/table
In general I think that having img and imgcaption (or whatever they are
called) enclosed by a single element is a better idea since the increased
simplicity makes rendering easier. For example, how would you expect a browser
to render this?:
pFoo
img id=bar
pFoobar
pBaz
imgcaption for=barPictures are nice!/imgcaption
In all current UAs I guess it would render something like:
Foo
img
Foobar
Baz
Pictures are nice
But I can't think of many situations where a figure's caption should be separate
from the figure itself and, from the discussion above, it seems that some people
would expect:
Foo
img
Pictures are nice
Foobar
Baz
Which is hard (impossible?) to implement in legacy clients (e.g. via script, if
the DOM is to be unchanged) and harder to implement in future clients.
Another issue to consider is the possibility of multiple images with a single
caption (this is very common in scientific papers, print magazines, etc.). A
construct like
figure
img
img
img
imgcaption
/figure
might be enough to support this (the details are, I think, non-trivial);
something that requires the caption to point to exactly one image cannot.
--
Eternity's a terrible thought. I mean, where's it all going to end?
-- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Nov 22, 2006, at 19:35, Alexey Feldgendler wrote: label for=fig1 type=title.../label label is not good, because it is reasonable to style form control labels the way the platform styles labels, but the styling may not be appropriate for figure captions. Also, the for attribute is now supposed to refer to a form control. I think it is better to introduce a figcaption or something than to confuse what label is. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Andrew Fedoniouk wrote: From: Lachlan Hunt [EMAIL PROTECTED] Andrew Fedoniouk wrote: E.g. the engine allows to define following: select id=color-selector popup table tr td role=option value=#00FF00... td role=option value=#FF... /tr /table /popup /select to be able to define something like this: http://www.terrainformatica.com/sciter/screenshots/color-chooser.png http://www.terrainformatica.com/htmlayout/images/selects3.jpg A better way to implement that without embedding presentational markup in the HTML would be to use an XBL template, bound to an ordinary select element. You could write all the markup you need to render the colour chooser or periodic table in the XBL template, which is populated by the values from the option elements. That has the advantage of providing better fallback in legacy UAs. 1) About that presentational markup sentence Semanticly speaking color table is a table and periodic table is a table too. This is exactly the case for what table was designed. Think about accessibility and you will get an idea why table is better in this case. They're a list of colors, not a color table. If you wanted a table, you could just create a table with input type=radio elements. However, this is probably an example of a situation where a color picker control would be better: | input type=color name=foreground value=red Both your use of select (for its popup behavior on most browsers) and your use of table (to organize the colors into rows and columns) are presentational, because what you're really doing is building the UI for a color picker. The user can just as easily select a properly styled radio button from a table, and with a little scripting it would look like a color picker and still degrade gracefully on user agents that don't even support Javascript or CSS, let alone your legacy-intolerant nested markup. (A better approach for using select to pick colors may be to allow the user of CSS table layout within the select element. You could style the optgroup elements as table rows and the option elements as table cells. Is there anything in the specs that says user agents can't already do this?) 2) XBL is useless if your engine is not capable to do popups in principle. it is simply nothing to bind with for your data. Actually, XBL 2.0 (and the original XBL, for that matter) can bind to anything that CSS can select, so that would be more a lack of support by the user agent than a shortcoming of XBL. However, even if it did fail, the user hasn't lost the ability to use the select control, so the fallback is acceptable. 3) Lifecycle of popup element can be complex - XBL is not the best thing to deal with this. While popups would be a nice addition, they are behavioral and presentational, not semantic. It would be better to provide proper styling and scripting mechanisms to deal with this instead of forcing people to use non-semantic markup. Then those mechanisms could be bound to proper fallback markup using XBL. 4) XBL is the ability to map elements to script. Just add attribute prototype or behavior to the CSS and you will get almost perfect binding of class of DOM elements to the class in script or code in other place. I'm not sure what you mean, but XBL 2.0 is already defined as using a CSS property to bind a behavior to an element. However, instead of providing a hard-coded behavior, XBL allows an implementation of that behavior based on existing web standards.
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Nov 13, 2006, at 7:43 PM, Alexey Feldgendler wrote: ... I believe HTML should have an element for every attribute intended to hold human-readable text. A raw idea can go like this: img id=img1 src=... label for=img1 type=title.../label Here, label holds a value which should be treated the same way like the title attribute on img, except that it can contain nested markup. This would be useful for all attributes defined as %Text in HTML -- in HTML4, these are ABBR, ALT, LABEL, STANDBY, SUMMARY, TITLE. ... You would need to stipulate that title= couldn't contain any a elements. A link in a tooltip would usually be impossible to click. :-) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Wed, 15 Nov 2006 09:42:11 +0600, Matthew Paul Thomas [EMAIL PROTECTED] wrote: I believe HTML should have an element for every attribute intended to hold human-readable text. A raw idea can go like this: img id=img1 src=... label for=img1 type=title.../label Here, label holds a value which should be treated the same way like the title attribute on img, except that it can contain nested markup. This would be useful for all attributes defined as %Text in HTML -- in HTML4, these are ABBR, ALT, LABEL, STANDBY, SUMMARY, TITLE. You would need to stipulate that title= couldn't contain any a elements. A link in a tooltip would usually be impossible to click. :-) Maybe, or maybe not. I'd say not recommended because not all ways of rendering such labels allow clicking links and other interactive elements like inputs. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey Feldgendler wrote: On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon [EMAIL PROTECTED] wrote: Couldn't we extend the label element to work for images as well as form elements? The for attribute would provide the explicit link to the image that would take the label's contents out-of-stream for screen readers, and would likewise (with some CSS changes, I suppose) allow the caption to be positioned correctly relative to the image for visual browsers. Today's browsers seem to have problems about label outside of form. I'm not aware of the problem. The worst that seems to happen when you use a label for= element with an img is that the label element becomes just a stylable inline element. That would seem to be the best fallback styling we can hope for in a caption/label. If you're referring to focus passing, WF2 already places platform-specific limits on user agents that prevent focus passing in certain situations. Because most platforms don't give an image focus when you click on it's label (or caption), WF2 would indirectly define label as not passing focus in that situation. I was actually thinking of something like this: | figure | img id=imageid [...] | label for=imageid | Image caption text. | /label | figure ...Where fallback content is ignored by figure: | figure | table | trtd | img id=imageid [...] | /td/tr | trth | label for=imageid | Image caption text. | /label | /th/tr | /table | figure So, in the above, the UA would treat the second example as if it where the first.
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Alexey notes: With CSS3 it's possible to display the value of title attribute in the visual flow. For older UAs a JS implementation is trivial. I didn't know that about CSS3, and that would be a good solution except where the end user has specified a local stylesheet to override the designer's style specs. Some users don't allow or don't recognize javascript, either, so when I use script I have to allow for alternative presentation. The drop-down menu I'm using degrades to an unordered list of links without javascript, for example. Considering all that, I still think captioning rightfully belongs in the HTML/XHTML semantic structure. After reflecting on your points and others, Alexey, I do expect more of a caption than I expect of a simple attribute. Most importantly, I expect it to be visible by default if I have a visible picture. For that reason, I agree now with those who suggest a CAPTION (or LEGEND) element, rather than an attribute. I especially like Matthew Paul Thomas' thinking on this: I suggest that this element behave in the opposite way from alt=: whereas alt= should be presented only if the image itself is *not* presented, the caption element should be presented only if the image itself *is* presented. Otherwise there would be the same problem with non-sequiturs in non-visual media as there is with descriptive alt=. Simple, elegant, functional ... so please, somebody shoot holes in this and make it an even better idea. I apologize if I've gone over old ground on this. I'm new to this list, and others have indicated that this has been discussed before. Has it been decided, though? To me, it seems a very basic and urgent need in the HTML/XHTML specs. Jeff Seager West Virginia Division of Rehabilitation Services
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Sat, 11 Nov 2006 21:43:47 +0600, Jeff Seager [EMAIL PROTECTED] wrote: How is your proposed CAPTION attrbute different from the TITLE attribute already included in HTML4? Alexey, the only problem I have with title in this context is in the current UA implementations. I'm not as familiar with the W3C specs as many people here, but in practice title doesn't display, does it? In Firefox, at least, it displays when the cursor hovers over it. I don't want to explain to non-savvy users that they need to hover over images to get the caption. Instead, we should have a simple way to attach a caption that all user agents interpret as being associated with a particular image. The visual display would be controlled with CSS, but its context should be readily understood by JAWS, Window Eyes, and other non-graphical user agents. With CSS3 it's possible to display the value of title attribute in the visual flow. For older UAs a JS implementation is trivial. The problem is that captions can and do have substructure. For instance, a caption might include multiple emphasized or strongly emphasized sections. Attributes just aren't powerful enough for this. Why is that, Elliotte? Maybe I just expect less of a caption. After all, don't we just need it to provide an explanation for why or how this graphic image relates to content? It's the content that should carry the real burden. A caption may fulfill a more elaborate purpose in technical and scientific papers, but I don't see that as inherently necessary. I'm open to understand differently, though. If you don't expect of a caption more than of a simple attribute, then the existing title attribute should fit your needs. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Jeff Seager wrote: What's clearly missing from the IMG specification is an appropriate means for pairing each picture or graphic with a caption. Neither ALT nor LONGDESC is appropriate for this. My current solution, borrowed from Darren Brierton of Vancouver ( http://www.dzr-web.com/people/darren/blog/2005/02/09/image-captions-in-xhtml/ http://www.dzr-web.com/people/darren/blog/2005/02/09/image-captions-in-xhtml/ ), is to embed the image as the DT in a definition list, with the caption as the DD. Semantically, this makes sense because the caption does in fact define the image by adding both meaning and context for visual and non-visual users. But assumptions have already been made in the specifications about the nature of a definition list, and captioning was not among those assumptions, so it's a little clunky to bend the rules like this. I would argue that, unless any UA does something meaningful with the dtdd pair when one is an image (unlikely since this is not an accepted way of generating captions, but not impossible), marking up captions in this way is no more useful than using e.g. div img Caption /div (I do not mean to suggest that you are using bad markup here; I'm just starting to wonder, in general, whether all the discussions that people have about the most meaningful way to markup a particular construct that is not explicitly mentioned in the spec are actually as worthwhile as the amount of effort that is put into them would suggest. I suspect, at least in many cases, it is not since no UA can guess what the markup is supposed to represent without actual AI). A better way would be to semantically attach the caption or cutline to the image itself, so its display is paired naturally. In this way, the width of the cutline would be dictated (unless overruled in the stylesheet) by the width of the image. I'm suggesting that CAPTION be adopted as a new attribute of the IMG element, as it is already for the TABLE element. This has previously been brought up but typically as a caption element since this would allow markup inside the caption. I (and I think others too) agree that this is an important addition we should make to HTML. -- The universe doesn't care what you believe. The wonderful thing about science is that it doesn't ask for your faith, it just asks for your eyes --- http://xkcd.com/c154.html
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Jeff Seager wrote: A better way would be to semantically attach the caption or cutline to the image itself, so its display is paired naturally. In this way, the width of the cutline would be dictated (unless overruled in the stylesheet) by the width of the image. I'm suggesting that CAPTION be adopted as a new attribute of the IMG element, as it is already for the TABLE element. I don't think caption should be an attribute, an element maybe, but not an attribute. The problem is that captions can and do have substructure. For instance, a caption might include multiple emphasized or strongly emphasized sections. Attributes just aren't powerful enough for this. Given that, I suspect we're probably better off just using regular paragraphs in text with appropriate CSS instructions rather than introducing a new element. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Fri, 10 Nov 2006 01:57:19 +0600, Jeff Seager [EMAIL PROTECTED] wrote: A better way would be to semantically attach the caption or cutline to the image itself, so its display is paired naturally. In this way, the width of the cutline would be dictated (unless overruled in the stylesheet) by the width of the image. I'm suggesting that CAPTION be adopted as a new attribute of the IMG element, as it is already for the TABLE element. How is your proposed CAPTION attrbute different from the TITLE attribute already included in HTML4? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Elliotte Harold wrote: Given that, I suspect we're probably better off just using regular paragraphs in text with appropriate CSS instructions rather than introducing a new element. I strongly disagree. The caption is intrinsically linked to the image and, by making this relationship explicit, UAs should be able to provide more helpful information. For example in something like a scientific paper, figures and their caption are out of the flow in the sense that one can read all the figures and captions separately to the main body of text. With a caption element an aural UA can read the captions only on user request, improving the flow of the text. One can also imagine other types of UA making use of this information e.g. the googlebot to improve image search. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Elliotte Harold wrote: Jeff Seager wrote: A better way would be to semantically attach the caption or cutline to the image itself, so its display is paired naturally. In this way, the width of the cutline would be dictated (unless overruled in the stylesheet) by the width of the image. I'm suggesting that CAPTION be adopted as a new attribute of the IMG element, as it is already for the TABLE element. I don't think caption should be an attribute, an element maybe, but not an attribute. The problem is that captions can and do have substructure. For instance, a caption might include multiple emphasized or strongly emphasized sections. Attributes just aren't powerful enough for this. Given that, I suspect we're probably better off just using regular paragraphs in text with appropriate CSS instructions rather than introducing a new element. I agree, attributes are too weak (eg. couldn't support http://www.w3.org/TR/ruby/ ). Dan
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon [EMAIL PROTECTED] wrote: Couldn't we extend the label element to work for images as well as form elements? The for attribute would provide the explicit link to the image that would take the label's contents out-of-stream for screen readers, and would likewise (with some CSS changes, I suppose) allow the caption to be positioned correctly relative to the image for visual browsers. Today's browsers seem to have problems about label outside of form. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 10 nov. 2006 à 14:19, Alexey Feldgendler a écrit :
On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon
[EMAIL PROTECTED] wrote:
Couldn't we extend the label element to work for images as well
as form
elements? The for attribute would provide the explicit link to
the image
that would take the label's contents out-of-stream for screen
readers, and would likewise (with some CSS changes, I suppose)
allow the caption to be
positioned correctly relative to the image for visual browsers.
Today's browsers seem to have problems about label outside of
form.
And today's browsers also have problems with caption outside a
table, which implies that my previously proposed markup for this:
figure
captioncaption text/caption
... figure content here ...
/figure
would not work correctly in today's browsers. But if you look at
things in another way, today's Firefox can't handle section,
aside, header, and footer correctly either (stopping the
section at the first block-level element!). So it seems that Web
Applications 1.0 already requires browser vendors to do some minor
changes to the DOM unknown markup created previously; maybe
supporting caption or label could be part of these changes.
Also, the last versions of Safari and Opera work fine with section,
but that's relatively new because not so long ago they couldn't.
Should we take this as a sign that browser vendors are willing to do
the necessary changes to work with the new elements? Could such
changes be extended to caption or legend?
What I like about the figure markup above is that it can be styled in
the same way as a table:
figure { display: table; }
caption { display: table-caption; }
which makes figure behave as a one-cell table, and caption behave
as the caption for that table (and you can play with `caption-side:
bottom` too). The only problem is that it doesn't work presently
because caption is completely ignored when outside a table.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Fri, 10 Nov 2006, Michel Fortin wrote: And today's browsers also have problems with caption outside a table, which implies that my previously proposed markup for this: figure captioncaption text/caption ... figure content here ... /figure would not work correctly in today's browsers. But if you look at things in another way, today's Firefox can't handle section, aside, header, and footer correctly either (stopping the section at the first block-level element!). The difference is that caption will never work, because of things like this: table caption figure img ... caption ...A... /caption /figure /caption ... /table ...which, for legacy compatibility reasons, must result in a DOM where the text with A ends up in a second caption element that is a child of the table element. The idea of having markup of this form: -container- -embedded-content-/ -caption- ... /-caption- /-container- ...is a fine idea, however, which has been proposed multiple times, and I'm sure we'll use some variant on that. We just can't use caption. Or label, because that's for form controls. I imagine we'll use legend. Parsers are a bit erratic with it right now, but we're requiring them to shape up for the parser part of the spec already, and the details element uses it already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 10 nov. 2006 à 19:16, Ian Hickson a écrit : The difference is that caption will never work, because of things like this: table caption figure img ... caption ...A... /caption /figure /caption ... /table ...which, for legacy compatibility reasons, must result in a DOM where the text with A ends up in a second caption element that is a child of the table element. I don't get it. Are you saying that caption cannot work outside table because it has to work a certain way when inside a table element? Or are you simply saying that figure cannot work because it cannot work inside a table caption? If supporting figure inside a caption is so important, browsers could treat figure in the same way they treat table when inside a caption. This works fine in current browsers: table caption table caption ...A... /caption ... /table /caption ... /table Now, I can't be sure how hard it'd be to make figure behave like table in this specific case, but as I already said. But any of these two samples seems completely ridiculous and confusing to me. Personally, I don't think any of the above cases should be allowed (caption has inline-level content in HTML4 by the way), and I it'd also be fine if browsers continue to do whatever they do when inside a caption element. And I don't see how any of this could prevent caption from creating a caption element in the DOM when *outside* a table. The idea of having markup of this form: -container- -embedded-content-/ -caption- ... /-caption- /-container- ...is a fine idea, however, which has been proposed multiple times, and I'm sure we'll use some variant on that. We just can't use caption. Or label, because that's for form controls. I certainly agree that label is a poor choice, because even if it's not necessarily a bad word for the concept, it's already used to mean something else which has little to do with image captions. I imagine we'll use legend. Parsers are a bit erratic with it right now, but we're requiring them to shape up for the parser part of the spec already, and the details element uses it already. I'm not sure I like legend as a word for captions. A legend -- in the context of a graph, a map, or a schema -- is a list of symbols or colors followed by some definition of what they represents on the figure. It's far different from a caption or the title of a figure. But legend, as an element, is worse: image captions and table captions are much more similar in concept and in default presentation than fieldset legends, which are some kind of title for a thematic group of form controls. By the way, I think legend for details is a perfect choice, because like fieldset, details is a functional regroupment, so legend becomes some sort of title for a group of related user interface elements. That definition works for both fieldset and details. If you add figure into the mix, legend becomes a title for something on the page. I think this would dilute the semantics and make the language less coherent. Even if it's a little more difficult, I think using caption is the right thing to do. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
