Re: [whatwg] figureimg* caption
I've changed figure and details again, hopefully for the last time. They now have unique elements for their legends: figure figcaption.../figcaption ... /figure details summary.../summary ... /details On Mon, 30 Nov 2009, Philip Jägenstedt wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) Hopefully this is now resolved. The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure At least to me, it looks clean enough and there are no serious parsing issues (just use document.createElement(figure) for IE). The caption is easy to style with figure *[caption] or any number of easy workarounds for browsers that don't support CSS attribute selectors (IE6?). I haven't been following the discussions on figure closely, so if this has already been discussed and rejected please link me in the right direction. I considered this, but it makes the processing much more complicated and fiddly everywhere, so I don't think it's a good design. On Mon, 30 Nov 2009, Tab Atkins Jr. wrote: The only thing you have to answer is what to do if there are multiple @caption elements in the figure. I suggest taking either the first or last; the exact choice is pretty much arbitrary. That's not the only problem... you also have to worry about the attribute being used on elements that can't really be moved around easily, or that are part of content; you have to consider what happens when the caption gets wrapped, there's the danger of authors misunderstanding how it works (since it's pretty unique as a mechanism), etc. e.g., consider: details Copying from volume A to X. Status: span legend54 files copied/span of 102 total. 23 minutes remaining. /details How would it render? What if you want to put paragraphs around each of those lines? On Mon, 30 Nov 2009, Nils Dagsson Moskopp wrote: Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 12:50:42 -0600: Note: I would style it with figure [caption] instead, to ensure you don't accidentally grab misplaced captions. I would like to style captions on top differently from captions underneath. What now ? Where the caption goes is a styling issue, so I don't think that's a problem really. Just style it when you position it. If you mean you want to apply meaning to where the element is in the DOM, then as Tab says, you can use selectors: On Mon, 30 Nov 2009, Tab Atkins Jr. wrote: figure [caption]:first-child or figure [caption]:last-child On Mon, 30 Nov 2009, Nikita Popov wrote: But still, why do we need the figure-wrapper? It would be cleaner syntax, in my eyes, if you could easily specify an element that is related as a caption to another element. Could look like this: img src=bunny.jpg alt=A Bunny id=bunny p caption=bunnyThe Cutest Animal/p or img src=bunny.jpg alt=A Bunny id=bunny p for=bunnyThe Cutest Animal/p This leads to very confusing markup. Just as we found h1ph2p to be confusing and are moving towards sectionh1psectionh2p /section/section, I think we should avoid using inter-element references where possible. Or used in the code-context: code id=mygreatscriptecho 0;/code strong for=mygreatscriptDoes nothing, but it's still cool!/strong I know, I know, for is used for labelled form elements, but I think, that is expresses very well the relation between content and caption. Furthermore, any related content could be marked up this way. I think it is _theoretically_ sound, but it is very hard to use in practice. For example, there is this strange hgoup-tag, that's used fore grouping title and subtitle: hgroup h1Somethind great happened/h1 h2Now some subtitle in a newspaper article.../h2 /hgroup If I wanted to place an image between title and subtitle of the article, it would look something like this: hgroup h1Somethind great happened/h1 figure ddimg src=Aphotoofit //dd dtDescr. of img./dt /figure h2Now some subtitle in a
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 7:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The @caption proposal isn't for an attribute on p only, but rather for an attribute on any element that is a child of a figure. (It's just that most of the time using a p is most appropriate.) Ah, OK. Well, given the circumstances, this does seem like the best approach, though I feel conditionally allowing certain attributes depending on an element's context is a step in the wrong direction. It's confusing given the way HTML will have worked up until that point; as a document author, although I expect elements themselves only to be allowed in certain contexts, I also expect them to carry all of their attributes with them when they are; i.e., attributes are perceived as belonging to the element within which they are set, not the parent of that element. Most of us agree that a more semantic element would be ideal here, yet we can't use one [yet] because of current technical limitations. That sounds like the very situation microformats was created to address. What if we used @itemprop as a placeholder for a future figure-caption element? To make things less verbose, figure could have an implied @itemscope and @itemtype unless specifically overwritten by the author. Ex: figure img src=figure.gif alt=graph p itemprop=captionThe findings/p /figure On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com wrote: It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. Is this issue being addressed by the latest DOM specification? It seems there should really be a standard behavior for browsers when encountering unknown or unexpected elements that ensures that the next version of HTML is not similarly encumbered by this.
Re: [whatwg] figureimg* caption
On Dec 2, 2009, at 12:58 AM, Hugh Guiney wrote: On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com wrote: It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. Is this issue being addressed by the latest DOM specification? It seems there should really be a standard behavior for browsers when encountering unknown or unexpected elements that ensures that the next version of HTML is not similarly encumbered by this. HTML5 parsing requirements will fix this both for legend and for unknown elements. For what it's worth, all non-IE browsers handle unknown elements in a consistent way, and IE can be made to do so by first creating an instance of said element in script. legend is not a new element though, it has a longstanding use in fieldset many of it's particular oddities stem from the fact that browsers have only expected it to appear inside fieldset, where it has specialized rendering. Regards, Maciej
Re: [whatwg] figureimg* caption
On Wed, 02 Dec 2009 03:58:32 +0100, Maciej Stachowiak m...@apple.com wrote: On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote: On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. I don't think keyboard accessibility is a problem for label. details itself can be made focusable. I believe the only technical issues with label are: 1) Some sites already have style rules for label based on the assumption that it is only ever used for form labels. So they would have to tweak their CSS to be able to use details. I don't think this argument is very strong. 2) Using label could create issues in present-day browsers if the label includes a form control. Specifically the label would be considered the label of the form control if it has no other label, which may not be appropriate. This is somewhat unlikely but not altogether impossible. 3) If label were used for the caption, it would not be possible to use label as a form control label inside the figure caption (use case: hot or not). 4) If label were used for the caption, it would not be possible to use label as the figure content (can't think of a compelling use case for this, but it's currently allowed). Opinions on the seriousness of these two issues vary, but I must concede that the dt/dd solution does not have these two specific problems. BTW the current alternate proposal in the HTML Working Group is to replace dt/dd with a fltcap element to use as the label for both figure and details: http://esw.w3.org/topic/HTML/ChangeProposals/DdDt . Regards, Maciej -- Simon Pieters Opera Software
Re: [whatwg] figureimg* caption
Philip Jägenstedt wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. Yes, I expect we'll see a lot of authors get them reversed, using the dd for the caption if they want the caption below the content. This is likely to occur since existing authors have already learned that dt comes before dd when used within a dl, and because old habbits die hard, they're likely to repeat the pattern within figure. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) Some additional reasons why using dt/dd in figure is a bad solution: The simplest workaround presented so far to solve the styling issue in IE is basically to do this: div class=figure figure ddimg src=image alt=.../dd dtCaption/dt /figure /div And then rather than style the figure itself, give some style to the div because some styles don't work properly when applied to the figure. This effectively makes the figure element itself entirely useless, especially given that all browsers lack support for it. It would be far easier for authors to just stick with this entirely hack free alternative that doesn't use the new elements: div class=figure img src=image alt=... p class=captionCaption/p /div At least until browsers actually implement support for figure and IE6/7's market share becomes negligible. It will take a couple of years for those events to occur, and there's no need to rush into using the new elements yet. The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure I was the first one to suggest that on IRC a while ago, but I'm not convinced it's a good idea. Although it's certainly better than using dt/dd. See IRC logs here. http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525 http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133 The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. Limiting the caption attribute to just the p element, or just div or something, might help, but I'd still expect authors to end up using it on other elements anyway. There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. Since Hixie is adamant that introducing a new element for the caption isn't going to happen, and I've yet to find a way to convince him otherwise, that leaves us with legend. Although legend has it's own styling issues in browsers, these will eventually be resolved in a couple of years. Therefore, the best solution is to revert the spec back to using legend for figure, but strongly discourage authors from using these new elements yet, until the implementation issues are resolved. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] figureimg* caption
The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. This does make sense. Would be really hard, for sure. There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. As caption and legend have much too many backwards compatibility issues, the only possible solution is either a new element or dropping the whole figure-thing. The second thing should really be taken into account. Better no syntax than bad syntax :) What tag-titles could be used to mark the captions up? I thought of desc or description (first is better). Does not seem to be taken, but I don't know whether it is as intuitive. (But I as a German, who can't speak English very well, would search for html5 image description next after html5 caption.) MfG Nikita Popov
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. There are a multitude of reset style sheets on the web today that don't seem to have a problem removing virtually all default styling from elements. It would not be difficult to modify one to strip a @caption element down to bare bones and then restyle as desired. ~TJ
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 15:33:28 +0100, Nikita Popov pri...@ni-po.com wrote: There are only 2 sensible options for element choices: legend or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. As caption and legend have much too many backwards compatibility issues, the only possible solution is either a new element or dropping the whole figure-thing. or a new attribute -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] figureimg* caption
Tab Atkins Jr. wrote:
On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
To some extent, it even makes it difficult for authors to provide reasonable
styles if they can't guarantee which elements content writers will choose
for their caption. Imagine designing a CMS template with some default
styles for figure and caption, the CSS in the template would have to deal
with so many possible element choices just for the caption, it'll be
difficult to get it right and test everything.
There are a multitude of reset style sheets on the web today that
don't seem to have a problem removing virtually all default styling
from elements. It would not be difficult to modify one to strip a
@caption element down to bare bones and then restyle as desired.
Applying reset styles alone and making all elements look the same
basically defeats the purpose of being able to use a range of different
elements, and is very likely not what an author would ultimately want.
Reset styles are just used to give different elements a more level
playing field for new styles, and so authors would then still have to go
through all the elements and style them appropriately for use as a
caption. Plus, authors have to worry about cascading issues from other
styles in their own stylesheets.
Say, for instance, an author had applied special styles to paragraphs in
some special type of section:
#foo p { margin-left: 1em; }
And then a content writer puts a figure in there using p caption, but
the CSS author failed to adequately account for figures being used in
that section, despite doing:
p[caption] { margin: 0; }
Due to specificity, the first rule would apply regardless and the
caption would get a potentially unwanted margin.
I know there are ways to work around the issue, such as using !important
or finding ways to increase the specificity of the latter selector, but
the point is that introducing unnecessary element clashes creates
needless complexities that should be avoided.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 9:07 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Applying reset styles alone and making all elements look the same basically
defeats the purpose of being able to use a range of different elements, and
is very likely not what an author would ultimately want.
Heh, you either want consistent styling, in which case you use a
reset, or you want element-specific styling, in which you don't.
Can't have it both ways. ^_^
Reset styles are just used to give different elements a more level playing
field for new styles, and so authors would then still have to go through all
the elements and style them appropriately for use as a caption. Plus,
authors have to worry about cascading issues from other styles in their own
stylesheets.
Say, for instance, an author had applied special styles to paragraphs in
some special type of section:
#foo p { margin-left: 1em; }
And then a content writer puts a figure in there using p caption, but the
CSS author failed to adequately account for figures being used in that
section, despite doing:
p[caption] { margin: 0; }
Due to specificity, the first rule would apply regardless and the caption
would get a potentially unwanted margin.
I know there are ways to work around the issue, such as using !important or
finding ways to increase the specificity of the latter selector, but the
point is that introducing unnecessary element clashes creates needless
complexities that should be avoided.
This is a valid complaint.
~TJ
Re: [whatwg] figureimg* caption
On 1 Dec 2009, at 14:33, Nikita Popov wrote: As caption and legend have much too many backwards compatibility issues It's not bad I think. I've played a little with the live DOM viewer and this seems usable: figure content captiondiv class=captionfoo/div/caption /figure caption start/end tag is completely ignored, so at lest there's no negative side effect. You only need another styling hook. It's not any worse than suggested hack for dd. To ease transition, HTML5 might allow wrapping caption in table without any rows: figure content tablecaptionfoo/caption/table /figure This gives good DOM and styling in all browsers (with createElement hack in IE of course). This caption can be styled differently from real table captions using caption:only-child selector. Saying that caption of table in figure is also figure's caption IMHO makes sense even for real tables (is there a need for doubly-captioned figure-table?) -- regards, Kornel
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 14:28:32 +0100, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
Philip Jägenstedt wrote:
As currently speced, the proper usage of figure is:
figure
ddimg src=bunny.jpg alt=A Bunny/dd
dtThe Cutest Animal/dt
/figure
Apart from all that has been said about legacy parsing, leaking style in
IE, etc I would (perhaps not be the first to) add:
1. It seems quite easy to confuse or mistype dd/dt. Without guessing how
often authors will get it wrong, I think everyone agrees that (all else
equal) a syntax which is harder to confuse/mistype is better.
Yes, I expect we'll see a lot of authors get them reversed, using the dd
for the caption if they want the caption below the content. This is
likely to occur since existing authors have already learned that dt
comes before dd when used within a dl, and because old habbits die hard,
they're likely to repeat the pattern within figure.
2. Only the caption needs to be marked up, the content is implicitly
everything else. While some content may need a wrapping element for
styling, e.g. img usually does not.
3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone
else's.)
Some additional reasons why using dt/dd in figure is a bad solution:
The simplest workaround presented so far to solve the styling issue in
IE is basically to do this:
div class=figure
figure
ddimg src=image alt=.../dd
dtCaption/dt
/figure
/div
And then rather than style the figure itself, give some style to the div
because some styles don't work properly when applied to the figure. This
effectively makes the figure element itself entirely useless, especially
given that all browsers lack support for it.
It would be far easier for authors to just stick with this entirely hack
free alternative that doesn't use the new elements:
div class=figure
img src=image alt=...
p class=captionCaption/p
/div
At least until browsers actually implement support for figure and
IE6/7's market share becomes negligible. It will take a couple of years
for those events to occur, and there's no need to rush into using the
new elements yet.
The main difficulty with coming up with something better seems to have
been finding a name for an element which isn't already taken. If that's
the only issue, why not just take some inspiration from time pubdate
and use an attribute instead?
figure
img src=bunny.jpg alt=A Bunny
p captionThe Cutest Animal/p
/figure
I was the first one to suggest that on IRC a while ago, but I'm not
convinced it's a good idea. Although it's certainly better than using
dt/dd.
See IRC logs here.
http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525
http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133
The original idea for using the attribute was that it could apply to a
wide range of elements, like p, div, etc. But that makes it difficult
for browsers to provide sensible default styling for captions, since it
requires carefully overriding existing defaults for so many other
elements.
You only need to provide styles for the elements you're using which
wouldn't work with a simple generic style such as.
figure[caption] { margin-left: 1em; font-weight: bold; }
Please, no examples where this doesn't work. It's obvious, but also very
easy to fix.
To some extent, it even makes it difficult for authors to provide
reasonable styles if they can't guarantee which elements content writers
will choose for their caption. Imagine designing a CMS template with
some default styles for figure and caption, the CSS in the template
would have to deal with so many possible element choices just for the
caption, it'll be difficult to get it right and test everything.
Imaginary template language:
figure
@content@
div caption@caption@/div
/figure
Does everything you could do with a new element. Almost everyone else will
probably get by without wrapping divs though.
Limiting the caption attribute to just the p element, or just div or
something, might help, but I'd still expect authors to end up using it
on other elements anyway.
There are only 2 sensible options for element choices: legend or
introducing a new element. Using dt/dd is *not* and was never a
sensible choice for figure, and the idea must be dropped.
Since Hixie is adamant that introducing a new element for the caption
isn't going to happen, and I've yet to find a way to convince him
otherwise, that leaves us with legend.
Although legend has it's own styling issues in browsers, these will
eventually be resolved in a couple of years. Therefore, the best
solution is to revert the spec back to using legend for figure, but
strongly discourage authors from using these new elements yet, until the
implementation issues are resolved.
If all of the ideas are rejected I agree that it would be better to drop
figure, but I hope it won't come to that. A pointer to any parsing/styling
issues of legend
Re: [whatwg] figureimg* caption
On Tue, 01 Dec 2009 16:36:08 +0100, Philip Jägenstedt phil...@opera.com
wrote:
You only need to provide styles for the elements you're using which
wouldn't work with a simple generic style such as.
figure[caption] { margin-left: 1em; font-weight: bold; }
Please, no examples where this doesn't work. It's obvious, but also very
easy to fix.
Sent too early... this part is about author styles. I don't think there
should be a default browser style at all.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] figureimg* caption
Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward.
Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. The @caption proposal isn't for an attribute on p only, but rather for an attribute on any element that is a child of a figure. (It's just that most of the time using a p is most appropriate.) ~TJ
Re: [whatwg] figureimg* caption
On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote: On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. I don't think keyboard accessibility is a problem for label. details itself can be made focusable. I believe the only technical issues with label are: 1) Some sites already have style rules for label based on the assumption that it is only ever used for form labels. So they would have to tweak their CSS to be able to use details. I don't think this argument is very strong. 2) Using label could create issues in present-day browsers if the label includes a form control. Specifically the label would be considered the label of the form control if it has no other label, which may not be appropriate. This is somewhat unlikely but not altogether impossible. Opinions on the seriousness of these two issues vary, but I must concede that the dt/dd solution does not have these two specific problems. BTW the current alternate proposal in the HTML Working Group is to replace dt/dd with a fltcap element to use as the label for both figure and details: http://esw.w3.org/topic/HTML/ChangeProposals/DdDt . Regards, Maciej
[whatwg] figureimg* caption
As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure At least to me, it looks clean enough and there are no serious parsing issues (just use document.createElement(figure) for IE). The caption is easy to style with figure *[caption] or any number of easy workarounds for browsers that don't support CSS attribute selectors (IE6?). I haven't been following the discussions on figure closely, so if this has already been discussed and rejected please link me in the right direction. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] figureimg* caption
On Mon, Nov 30, 2009 at 12:41 PM, Philip Jägenstedt phil...@opera.com wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure At least to me, it looks clean enough and there are no serious parsing issues (just use document.createElement(figure) for IE). The caption is easy to style with figure *[caption] or any number of easy workarounds for browsers that don't support CSS attribute selectors (IE6?). I haven't been following the discussions on figure closely, so if this has already been discussed and rejected please link me in the right direction. I've proposed and supported this approach for a long time. It's never been rejected, but rather more-or-less ignored. I agree that it solves the issues nicely, and has an appropriate level of support in IE7+. (IE6 is still doing its gradual decline, and I've been allowed to ignore it since IE8 came out.) The only thing you have to answer is what to do if there are multiple @caption elements in the figure. I suggest taking either the first or last; the exact choice is pretty much arbitrary. Note: I would style it with figure [caption] instead, to ensure you don't accidentally grab misplaced captions. ~TJ
Re: [whatwg] figureimg* caption
Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 12:50:42 -0600: Note: I would style it with figure [caption] instead, to ensure you don't accidentally grab misplaced captions. I would like to style captions on top differently from captions underneath. What now ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] figureimg* caption
On Mon, Nov 30, 2009 at 10:41 AM, Philip Jägenstedt phil...@opera.com wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure At least to me, it looks clean enough and there are no serious parsing issues (just use document.createElement(figure) for IE). The caption is easy to style with figure *[caption] or any number of easy workarounds for browsers that don't support CSS attribute selectors (IE6?). I haven't been following the discussions on figure closely, so if this has already been discussed and rejected please link me in the right direction. I strongly agree with this. The strongest argument for me is that this much more closely matches how someone would use figure if you don't read the specification. The fact that you need to use dd/dt seems very unintuitive and I would expect people to forget to use them a lot. Especially since there would likely be no stylistic penalty for forgetting the dd/dt. dddt are used relatively rarely on the web today, even in situations where HTML4 says to use them. I think this speaks to their author unfriendlyness. / Jonas
Re: [whatwg] figureimg* caption
Yeah, I think this dd, dt thing isn't really intuitive. (Looks like
these two elements from definition lists are now used everywhere.)
Your proposed syntax looks more nice. But still, why do we need the
figure-wrapper? It would be cleaner syntax, in my eyes, if you could
easily specify an element that is related as a caption to another
element. Could look like this:
img src=bunny.jpg alt=A Bunny id=bunny
p caption=bunnyThe Cutest Animal/p
or
img src=bunny.jpg alt=A Bunny id=bunny
p for=bunnyThe Cutest Animal/p
Or used in the code-context:
code id=mygreatscriptecho 0;/code
strong for=mygreatscriptDoes nothing, but it's still cool!/strong
I know, I know, for is used for labelled form elements, but I think,
that is expresses very well the relation between content and caption.
Furthermore, any related content could be marked up this way. For
example, there is this strange hgoup-tag, that's used fore grouping
title and subtitle:
hgroup
h1Somethind great happened/h1
h2Now some subtitle in a newspaper article.../h2
/hgroup
If I wanted to place an image between title and subtitle of the article,
it would look something like this:
hgroup
h1Somethind great happened/h1
figure
ddimg src=Aphotoofit //dd
dtDescr. of img./dt
/figure
h2Now some subtitle in a newspaper article.../h2
/hgroup
The img doesn't really belong in the hgroup. Using the for-attr it would
look like this:
h1 id=something-great-happenedSomething great happened/h1
img src=Aphotoofit id=theimg /
p for=theimgDescr. of img./p
h2 for=something-great-happenedNow some subtitle in a newspaper
article.../h2
Here styling is the problem: The fors are all identical and can't be
distinguished. So maybe get the caption-attr. back in?
h1 id=something-great-happenedSomething great happened/h1
img src=Aphotoofit id=theimg /
p caption for=theimgDescr. of img./p
h2 subtitle for=something-great-happenedNow some subtitle in a
newspaper article.../h2
Which would be not so nice looking in XML ('caption=caption').
So maybe combine them (which would, too, solve the problem of usage of
for for forms. [Nice three fors...]]):
h1 id=something-great-happenedSomething great happened/h1
img src=Aphotoofit id=theimg /
p caption-for=theimgDescr. of img./p
h2 subtitle-for=something-great-happenedNow some subtitle in a
newspaper article.../h2
Philip Jägenstedt schrieb:
As currently speced, the proper usage of figure is:
figure
ddimg src=bunny.jpg alt=A Bunny/dd
dtThe Cutest Animal/dt
/figure
Apart from all that has been said about legacy parsing, leaking style
in IE, etc I would (perhaps not be the first to) add:
1. It seems quite easy to confuse or mistype dd/dt. Without guessing
how often authors will get it wrong, I think everyone agrees that (all
else equal) a syntax which is harder to confuse/mistype is better.
2. Only the caption needs to be marked up, the content is implicitly
everything else. While some content may need a wrapping element for
styling, e.g. img usually does not.
3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone
else's.)
The main difficulty with coming up with something better seems to have
been finding a name for an element which isn't already taken. If
that's the only issue, why not just take some inspiration from time
pubdate and use an attribute instead?
figure
img src=bunny.jpg alt=A Bunny
p captionThe Cutest Animal/p
/figure
At least to me, it looks clean enough and there are no serious parsing
issues (just use document.createElement(figure) for IE).
The caption is easy to style with figure *[caption] or any number of
easy workarounds for browsers that don't support CSS attribute
selectors (IE6?).
I haven't been following the discussions on figure closely, so if
this has already been discussed and rejected please link me in the
right direction.
Re: [whatwg] figureimg* caption
On Mon, 30 Nov 2009 19:50:42 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: The only thing you have to answer is what to do if there are multiple @caption elements in the figure. I suggest taking either the first or last; the exact choice is pretty much arbitrary. Make it invalid and have any algorithms that extract captions (if there are/will be any) use the first element with @caption. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] figureimg* caption
Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 13:00:00 -0600: On Mon, Nov 30, 2009 at 12:57 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 12:50:42 -0600: Note: I would style it with figure [caption] instead, to ensure you don't accidentally grab misplaced captions. I would like to style captions on top differently from captions underneath. What now ? figure [caption]:first-child or figure [caption]:last-child Apparently, you did not comprehend my question and incorrectly assumed that I would always use multiple captions. So, to make that clear: Without a clear content wrapper, I cannot style a preceding caption differently from a following caption. Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] figureimg* caption
On Mon, Nov 30, 2009 at 1:06 PM, Nikita Popov pri...@ni-po.com wrote: Your proposed syntax looks more nice. But still, why do we need the figure-wrapper? It would be cleaner syntax, in my eyes, if you could easily specify an element that is related as a caption to another element. Could look like this: img src=bunny.jpg alt=A Bunny id=bunny p caption=bunnyThe Cutest Animal/p or img src=bunny.jpg alt=A Bunny id=bunny p for=bunnyThe Cutest Animal/p People will very commonly use a wrapper in any case, for styling the figure+caption together. For example, putting a border and background on it and positioning it. As well, using a wrapping element to implicitly scope things is easier than explicitly using indirection like @for. I always prefer to do labeltext input/label instead of label for=footext/labelinput id=foo, for example, because it's just plain easier to maintain. ~TJ
Re: [whatwg] figureimg* caption
Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 13:34:27 -0600: Apologies, but I have no idea what you're talking about and can only assume that we're both misunderstanding each other. […] You were right. Mea culpa, I apparently left my sense of logic at the door. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] figureimg* caption
On 01/12/2009, at 6:28 AM, Tab Atkins Jr. wrote: People will very commonly use a wrapper in any case, for styling the figure+caption together. For example, putting a border and background on it and positioning it. I agree with the inclusion of a wrapper in that in the standard use-case the entire figure is likely to be floated in a document; I can't think of any situation where captions would be in a different container than the element it refers to. Is there a semantic reason for p caption rather than simply repurposing the caption element itself? It seems to me that captions in this context are conceptually identical to captions for tables? I would imagine all of these to be legal (with both figure and caption being explicitly block-level elements): figure img / captionFoo/caption /figure figure captionFoo/caption img / /figure figure div img / /div captionFoo/caption /figure figure div img / /div div captionFoo/caption /div /figure Cheers, Kit Grose User Experience + Tech Director, iQmultimedia (02) 4260 7946 k...@iqmultimedia.com.au iqmultimedia.com.au
Re: [whatwg] figureimg* caption
On Mon, Nov 30, 2009 at 6:07 PM, Kit Grose k...@iqmultimedia.com.au wrote: Is there a semantic reason for p caption rather than simply repurposing the caption element itself? It seems to me that captions in this context are conceptually identical to captions for tables? Not a semantic reason, just a practical one. All existing browsers do something completely wrong when they encounter caption outside of a table. It's at least as bad as their handling of legend outside fieldset. Otherwise, yes, caption would definitely be the ideal. ~TJ
