11:58
<OmegaJunior>
:)
12:56
<zcorpan>
hsivonen: http://forums.whatwg.org/viewtopic.php?t=114
12:57
<zcorpan>
<audio>'s transparent content model and <figure>'s content model don't seem to work together
12:59
<hsivonen>
zcorpan: in spec or in my impl?
12:59
<zcorpan>
in the spec
12:59
<hsivonen>
so does validator.nu have a bug?
12:59
<zcorpan>
not sure
13:00
<OmegaJunior>
But audio is embedded content, which is allowed in figure
13:00
<zcorpan>
yes, however <audio> has a transparent content model
13:00
<hsivonen>
OmegaJunior: Have you checked the latest spec on <audio>? you should do the format fallback using <source> instead of nested <audio>
13:01
<OmegaJunior>
Semi-transparent, does that make a difference?
13:01
<zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-documents0.html#transparent0
13:02
hsivonen
isn't a fan of transparent content models
13:02
<OmegaJunior>
format fallback instead of nested? The latest spec says to nest source element inside audio element
13:03
<OmegaJunior>
zcorpan, that part on transparent content model makes my implementation correct and the validator wrong.
13:04
<zcorpan>
<figure><legend></legend><audio src=x>TEST</audio></figure> isn't conforming because <figure><legend></legend>TEST</figure> isn't
13:04
<OmegaJunior>
I must say, it's highly confusing.
13:04
<hsivonen>
OmegaJunior: you have two nested <audio> elements
13:04
<hsivonen>
I'm reviewing the schema for bugs
13:04
<zcorpan>
it seems to me that this is a bug in the spec
13:04
<OmegaJunior>
Yes, hsivonen, I do now... I started out with one audio element and two nested sources
13:05
<OmegaJunior>
I'll change that, but it'll have the same effect.
13:05
<hsivonen>
IIRC, this is a spec bug
13:05
<hsivonen>
I think I've mentioned this to Hixie
13:07
<hsivonen>
OmegaJunior: figure wants an embedded content element
13:07
<hsivonen>
OmegaJunior: and <audio> is transparent
13:07
<OmegaJunior>
Semi-transparent?
13:07
<hsivonen>
OmegaJunior: so the result is that the audio element wants an embedded child too
13:07
<hsivonen>
OmegaJunior: semi is about <source>
13:08
<OmegaJunior>
OK
13:08
<hsivonen>
so Validator.nu is unhelpful here, but it's really a spec issue
13:08
<OmegaJunior>
So removing the figure element should solve that problem
13:08
<hsivonen>
OmegaJunior: yes
13:09
<hsivonen>
This should probably be fixed by allowing text blocks as figures
13:10
<OmegaJunior>
Or maybe let media elements be real embed content?
13:10
<zcorpan>
they are embedded content
13:10
<OmegaJunior>
Spec says:
13:10
<OmegaJunior>
Contexts in which this element may be used:
13:10
<OmegaJunior>
As the only embedded content child of a figure element.
13:10
<OmegaJunior>
So use in figure element should be according to spec
13:11
<OmegaJunior>
thus spec contradicts self
13:11
<zcorpan>
OmegaJunior: indeed, as we said it's a bug in the spec :)
13:11
<OmegaJunior>
OK :)
13:11
<OmegaJunior>
Thanks!
13:11
<zcorpan>
np
13:12
<hsivonen>
OmegaJunior: use of <audio> in <figure> is OK. but the transparent content model sucks in that case, because then the content of <audio> needs to be embedded content, too
13:13
<OmegaJunior>
So basically using block-level elements inside an audio element is impossible?
13:13
<OmegaJunior>
As fallback content?
13:14
<zcorpan>
yes (since the other context where <audio> is allowed is where strictly inline-level content is allowed)
13:15
<hsivonen>
OmegaJunior: impossible per current spec when audio occurs as the child of figure
13:15
<hsivonen>
oh, and what zcorpan said
13:16
<OmegaJunior>
That's going to provide a lot of feedback...
13:16
<OmegaJunior>
I can't use block- nor inline-level elements anywhere inside an audio element, according to the validator.
13:17
<OmegaJunior>
Basically this renders fallback content useless, as you can't provide one or more hyperlinks as alternatives to the content.
13:18
<hsivonen>
OmegaJunior: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010790.html
13:19
<hsivonen>
interestingly, Google didn't find that message with relevant keywords
13:19
<OmegaJunior>
Did you get an answer to that question?
13:22
<OmegaJunior>
That required descendant that I'm missing... that might be the embedded content you ask about in your question of last April.
13:22
<zcorpan>
OmegaJunior: it's probably on the list of open issues
13:23
<hsivonen>
OmegaJunior: I thought Hixie acknowledged it, but I can't find anything to that effect in the logs
13:23
<hsivonen>
OmegaJunior: yes. my guess is that the error goes away if you put an <img> or <embed> there...
13:24
<OmegaJunior>
I hope this confusion will be edited out before this thing goes live... say, in the next 14 years.
13:24
<hsivonen>
OmegaJunior: I hope so, too.
13:25
<hsivonen>
OmegaJunior: occasionally I take matters into my own hands if the spec says something silly, but in this case I'm going with the letter of the spec
13:26
<zcorpan>
the email is in the graphics-video folder in http://www.whatwg.org/issues/
13:26
<hsivonen>
OmegaJunior: <font> and style='' would be examples of me overriding the spec optimistically.
13:26
<OmegaJunior>
OK :)
13:33
<OmegaJunior>
Well, I finally found something that makes the validator happy
13:33
<OmegaJunior>
I did enter an embed element into the audio element
13:34
<OmegaJunior>
And moved my fallback content (what I consider fallback) outside of the figure
13:34
<OmegaJunior>
But the embed element itself can't have fallback content...
13:35
<OmegaJunior>
So it's either one of the sources, or an embed, or nothing.
13:35
<zcorpan>
i would suggest to ignore any error messages regarding <figure><audio>
13:36
<OmegaJunior>
That works too...
13:37
<zcorpan>
but links would probably be useful also for people with html5 browsers, so it makes sense to place the links outside the <audio>
13:38
<OmegaJunior>
Though that is true, it also makes sense to put them inside the element as fallback content.
13:38
<zcorpan>
yeah, if you want to hide the links from people with html5 browsers
13:39
<hsivonen>
(fallback is for legacy browsers--not for HTML5 browsers)
13:39
<hsivonen>
that is, fallback isn't for accessibility or codec fallback
13:40
<OmegaJunior>
Really?
13:40
<OmegaJunior>
That's different from what I expected.
13:40
<zcorpan>
it's like the contents of <iframe>
13:41
<zcorpan>
browsers that don't support <iframe> will use the contents
13:41
<OmegaJunior>
Well... I expect Opera to show the fallback content of an iframe if I tell it not to display iframes...
13:41
<zcorpan>
yes, then you disable support for iframes
13:42
<OmegaJunior>
And I expect to be able to enter a hyperlink as fallback content, so visitors will be able to browse to the uri themselves.
13:42
<OmegaJunior>
Those with iframe support don't need that link...
13:42
<zcorpan>
but you don't get the contents of iframes if the iframe references a 404 or something that is not supported
13:42
<zcorpan>
exactly
13:42
<OmegaJunior>
True
13:42
<zcorpan>
<audio> is the same
13:43
<OmegaJunior>
But then having only an embed element as fallback of content doesn't cover all bases, does it?
13:43
<zcorpan>
i don't understand the question
13:45
<OmegaJunior>
Well, suppose a user agent doesn't know html 5: it won't understand the audio element. Suppose it adheres only to the W3 recommendations of html and doesn't know the embed element either... then the user sees nothing.
13:45
<zcorpan>
right
13:45
<OmegaJunior>
Allowing a simple text as fallback content would at least indicate that something should be present.
13:46
<zcorpan>
yes
13:46
<OmegaJunior>
Lest we require the user to study the page source...
13:47
<OmegaJunior>
Thanks for the explanations! I'm heading off.
13:47
<zcorpan>
cya
15:50
<hsivonen>
aaronlev: is this thread on your radar: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-October/012642.html
15:50
<aaronlev>
hsivonen: barely
15:51
<aaronlev>
the expert on closed captioning technologies is Larry Goldberg from WGBH
15:51
<aaronlev>
they invented closed captioning and are on top of technical issues
15:51
<aaronlev>
i think we should get them into this conversation
22:24
Hixie
just replied to the highest-voted e-mail