04:43
<sephr>
Hixie: what'd the reasoning behind using language-XXX class for programming languages? ( http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-code-element )
04:43
<sephr>
that's so ambiguous
04:43
<sephr>
why not use media types?
04:43
<sephr>
s/what'd/what's/
04:45
<sephr>
some programming languages don't have registered media types, but type="application/x-pascal" seems much more appropriate than piggybacking on class
04:59
<Hixie>
sephr: there's no type="" attribute, and the use case isn't important enough to add one just for this
04:59
<Hixie>
sephr: the idea of using class="language-*" is just a suggestion for people who need some mechanism anyway
04:59
<sephr>
sure yeah
04:59
<sephr>
what is the standards legality of x-programming-x-{language}?
05:00
<Hixie>
you mean as a mime type?
05:00
<sephr>
no, as a language code
05:00
<Hixie>
as in lang=""?
05:00
<sephr>
for example, <code lang="x-programming-x-python">
05:00
<sephr>
yeah
05:00
<sephr>
it's valid, but it seems a little wrong to do
05:00
<Hixie>
programming languages aren't the same as natural languages
05:00
<Hixie>
they're orthogonal concepts
05:00
<sephr>
yeah
05:00
<Hixie>
you can have java with french variables, for instance
05:01
<sephr>
then you'd do x-programming-x-java-fr heh
05:01
<sephr>
actually I think you'd start with the fr tag
05:01
<Hixie>
no better than class="language-java", except for being more verbose and being of dubious validity :-)
05:02
<sephr>
I wish you didn't have to put x- before every single subtag
05:02
<sephr>
if you start the first tag off with x-
05:02
<Hixie>
it's supposed to remind you that you're doing something bad :-)
05:02
<sephr>
heh
05:02
<sephr>
Hixie: oh btw, this is a little off-topic, but what are your thoughts on stripping x- internally?
05:03
<sephr>
for localization packages
05:03
<Hixie>
hm?
05:03
<sephr>
like en-US-x-Hixie and en-US-Hixie being the same
05:03
<Hixie>
wouldn't that violate the rules of the language tag processing model?
05:04
<sephr>
I know, but if x-Hixie is ever standardized, would it be reasonable to assume it'd be the same as x-Hixie or do you think it would change?
05:04
<Hixie>
it'd never be standardised
05:04
<sephr>
I strip the x-s in my l10n.js lib (https://github.com/eligrey/l10n.js)
05:04
<sephr>
if I put enough money behind it I'm sure you could get it standardized ;)
05:05
<sephr>
just formalize the spec more and be a little more verbose
05:05
<Hixie>
if a subtag is ever usefully standardised, the usage of the experimental subtag would be dwarfed by the usage of the official subtag, such that there'd be no reason to care about the experimental one
05:05
<Hixie>
anyway
05:05
<Hixie>
it seems clearly in violation of the rules and to be missing the point
05:05
<Hixie>
but you do what you like :-)
05:05
<sephr>
yeah I think I'll stop stipping the private use tags
05:06
<sephr>
if only we had a prog top tag
05:07
<sephr>
(was unrelated to the other message)
05:55
<heycam>
does CSS define whether text decorations are drawn under or over text?
05:55
<Hixie>
CSS 2.1 Appendix E would be where that would be defined
05:55
<Hixie>
if it's defined
05:56
heycam
takes a look
05:56
<heycam>
it does, thanks Hixie
05:57
<heycam>
and in an order consistent with SVG text, too. happy day. :)
06:02
<Hixie>
well that's lucky
09:28
<MikeSmith>
hsivonen: I'm reading http://hsivonen.iki.fi/aria-html5-bis/ while working on the ARIA schema updates, and I'm wondering if you ever got responses to the comments and questions you posted to the PFWG comments list
09:28
<MikeSmith>
e.g, http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0043.html
09:28
<MikeSmith>
about whitespace trimming
09:29
<MikeSmith>
jgraham: same question for you
09:29
<MikeSmith>
about aria-level
09:39
<jgraham>
MikeSmith: I can't find any evidence I got responses to those specific comments although I did to some other ones. But I may just be missing something
09:46
<AugustoF>
Sup
09:49
<hsivonen>
MikeSmith: there were some responses. I still suggest implementing the ARIA datatypes as HTML5 microsyntaxes rather than XSD datatypes
09:49
<MikeSmith>
jgraham: well, frankly, they should have responded to you directly in some way, with a public record of the response
09:49
<AugustoF>
I'm working in a project for a video social network in html5, someone aqui working with Video conferencing or peer-to-peer communication?
09:49
<MikeSmith>
hsivonen: OK
09:49
<hsivonen>
I still don't believe anyone really wants the XSD behaviors in a browser
09:49
<AugustoF>
here*
09:49
<MikeSmith>
yeah, I tend to agree with you there
09:50
<MikeSmith>
hsivonen: do you recall where you got the responses?
09:50
<MikeSmith>
e.g., was it private e-mail, or archived on a list
09:50
<MikeSmith>
and if so, which list?
09:51
<payman>
AugustoF: Ask your question and find out?
09:51
<MikeSmith>
jgraham: I am not sure but I believe it's a requirement that LC comments have to be publicly archived somewhere
09:52
<MikeSmith>
it is definitely a requirement that all LC comments must be responded to
09:52
<MikeSmith>
but even if your comments were not LC comments, the spirit of the process at least requires some formal response
09:53
<AugustoF>
payman I don't have just one question, btw I'm searching people to working in my project
09:53
<jgraham>
I think those were maybe not LC comments?
09:53
<jgraham>
I got some responses to some LC comments
09:53
<jgraham>
But nothing abour aria-level
09:55
<hsivonen>
MikeSmith: I think the responses were in their LC comment tracking app
09:58
<MikeSmith>
hsivonen: … which I think there is no public facet of…
09:58
<MikeSmith>
but I will check
09:59
<MikeSmith>
if they are using Dom's comment-tracker app, I am pretty sure it has a way to expose a public view while keeping some fields private to the WG
09:59
<MikeSmith>
jgraham: OK
10:02
<Facetalk>
Would anyone be interested in working on a project for make a social video network made ??partly in html5?
10:02
<MikeSmith>
hsivonen, jgraham : the specific problem with aria-level is that it's now mentioned in the HTML5 spec
10:02
<MikeSmith>
http://dev.w3.org/html5/spec/content-models.html#table-aria-strong
10:02
<MikeSmith>
for hgroup
10:02
<MikeSmith>
as is the "heading" role
10:02
<MikeSmith>
and, by design, neither aria-level nor the "heading" role are valid in the validator.nu ARIA schema
10:03
<MikeSmith>
hsivonen, jgraham: and so I would like to know what response if any PFWG gave to you about your comments and questions on those, and on any other ARIA features which are by design not supported in the validator.nu ARIA schema
11:34
<zcorpan>
MikeSmith: you're going full frontal willful violation against ARIA?
11:35
<zcorpan>
MikeSmith: think of the blind people!
11:35
<MikeSmith>
zcorpan: nothing like that
11:37
<zcorpan>
MikeSmith: only partial willful violation?
11:38
<MikeSmith_>
if, after reviewing the patch and seeing whether PFWG made changes to address his comments, he agrees that the schema needs to be changed, we can do it then
11:38
<MikeSmith_>
and/or we file HTML5 spec bugs to not require those attiributes
11:38
<MikeSmith_>
which actually, I think the spec may not at this point
11:39
<MikeSmith_>
in the case of aria-level and role=heading
11:39
<MikeSmith>
I thought it did when I first started putting the patch together but it seems now that the spec may not actually be requiring them
11:45
jgraham
doesn't entirely like the words "MikeSmith" and "full frontal" appearing in the same sentence
11:46
<MikeSmith>
heh