00:00
Dashiva
looks for shrimps to toss
00:00
<Lachy>
(that is, unless I'm mistaken about "barbie" being aussie slang)
00:01
<heycam>
it's certainly a commonly parodied contraction...
00:03
<sicking>
if they were having fosters at the barbie i think it's pretty safe to assume it's authentic Australian
00:03
<heycam>
lol
00:03
heycam
is always surprised to see fosters advertised when abroad
00:03
<Lachy>
sicking, real Aussies don't drink Fosters. That's the crap we export
00:04
<sicking>
Lachy, i know :)
00:06
<heycam>
is it en_UK or en_GB?
00:07
<heycam>
aspell doesn't seem to have en_AU support
00:09
<Lachy>
heycam, en-GB
00:09
<heycam>
hmm, i've always had LANG=en_AU.UTF-8
00:09
<Lachy>
I'm not sure what variants en-UK would have
00:09
<heycam>
i wonder if that underscore is wrong
00:10
heycam
gives up for now
01:03
<robburns>
zcorpan: saw your comments on tHTML. That div in head was an error on my part. Not at all the type of parsing I intended. Thanks for pointing it out.
01:26
<heycam>
does <script type="text/javascript;version=1.6"> mean anything special beyond <script type="text/javascript">?
01:28
<roc>
yeah, it enables language features
01:28
<heycam>
without a version, what does it default to?
01:28
heycam
is wondering how to expose JS-that's-not-ES232 features in batik
01:29
<roc>
you quickly reached the limits of my knowledge
01:29
<heycam>
:)
01:37
Hixie
wishes there was no out-of-band versioning data for JS
01:38
<heycam>
so basically i was wondering if it would be reasonable to make <svg:script type="text/javascript;version=1.6"> turn on the relevant feature flags in rhino
01:39
<heycam>
or perhaps even distinguish between {text,application}/javascript and {text,application}/ecmascript to turn on the features
01:40
<heycam>
currently all JS-and-not-ES features are turned off, and i'm enjoying using 'for each' and 'let' lately in my own project using rhino
01:40
<heycam>
so though it might be good to expose them somehow
01:41
<Hixie>
any reason they can't just be turned on by default?
01:41
<heycam>
only my lack of knowledge about what the appropriate thing to do is
01:43
gavin_
tries and fails to determine how gecko handles a missing version
01:44
<gavin_>
we end up with JSVERSION_UNKNOWN at http://mxr.mozilla.org/mozilla-central/source/dom/src/base/nsJSEnvironment.cpp#3676 , and I don't see where that case is handled
01:44
<gavin_>
(in the JS engine)
01:44
<gavin_>
I suppose that just means it falls back to "default" language features
01:45
<heycam>
might be http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsParserUtils.cpp#282 that does that
01:47
<gavin_>
oh, actually I misread
01:47
<gavin_>
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptLoader.cpp#391 takes another path if there is no version at all
01:49
<gavin_>
and in fact we'd actually end up in http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptLoader.cpp#442 without the type="" attribtue at all
01:49
<gavin_>
...and you already found that
01:50
heycam
goes to lunch, thanks for looking gavin_
01:51
<gavin_>
needed something to get my mind off fennec panning code :)
02:06
<Hixie>
good lord
02:06
<Hixie>
what have i gotten myself into
02:15
<Dashiva>
Is that a rhetorical question?
02:16
<othermaciej>
Hixie: it's hard to figure out a unique referent for that complaint
02:21
<Hixie>
the direct referrent was the big swamp of a mess around the presentational attributes for setting margins on <body>
02:21
<Hixie>
and more generally the rendering section as a whole
02:21
<Hixie>
and more generally still, html5.
02:22
<Dashiva>
Just a few more steps until all of creation
02:23
<Hixie>
i only took responsibility for html5 :-P
02:27
<Dashiva>
Pssh, surely you'll need something to do after 2022
02:29
<jruderman>
annevk: you might enjoy opera bug 246216
02:34
<Hixie>
Dashiva: i'll wait til 2022 to find out what i feel like doing :-P
02:40
<Hixie>
holy crap
02:40
<Hixie>
i can set the margins on a <body> element cross-domain in all four major browsers
02:41
<roc>
woohoo
02:41
<Hixie>
i can't think of any way to abuse that off the top of my head
02:41
<Hixie>
but that's surprising nonetheless
04:01
Dashiva
wonders if six separate replies at once really was the best way to move the discussion ahead
04:24
<Hixie>
Dashiva: any of them include use cases?
04:30
<Dashiva>
Looks more like the requesting uses cases kind
04:30
<Dashiva>
*use
04:30
<Hixie>
well at least it takes about use cases then i guess
05:03
<dbaron>
are the non-fieldset uses of <legend> in HTML5 intended to be display:block or display:inline ?
05:03
<Hixie>
block
05:03
<dbaron>
I'm guessing display:block, but I'm not sure...
05:03
<dbaron>
k
05:03
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#display-types
05:04
<Hixie>
(that section is very new and very much a work in progress; please let me know if you spot any mistakes but don't be surprised to see basic things wrong there)
09:22
<annevk>
jruderman, I'm not a huge fan of the mess that is CSS syntax, but sure :)
09:39
annevk
found a CSS 2.1 bug in IE8 by studying a handful of CSS 2.1 compliance tests from MS
09:40
<othermaciej>
heh
10:12
<annevk>
why should width="0032" not be valid?
10:14
<annevk>
Hixie, also "0032" does not return an error per the algorithm...
10:14
<annevk>
Hixie, for dimension values
10:17
<annevk>
Hixie, the step of collecting 0 characters after the fraction substeps is not necessary
10:17
<Hixie>
it's necessary to drop "0.9"
10:17
<Hixie>
and it doesn't matter what's valid
10:18
<Hixie>
in fact i've commented out the definition of "valid dimension value" in the working copy
10:18
<Hixie>
since nothing uses it
10:19
<annevk>
I see... my last comment still stands though
10:19
<Hixie>
oh after the fraction substeps
10:20
<Hixie>
wow what's that doing there
10:20
Hixie
removes
10:21
<annevk>
Hixie, "maps to the dimension property" uses both <var>properties</var> and <var>property</var>
10:22
<Hixie>
thx
10:39
annevk
finds out zcorpan joined the XML Core WG
10:39
<zcorpan>
about time :)
10:40
<zcorpan>
(not that you found out but that i joined)
10:44
<Hixie>
i saw that too
10:44
<Hixie>
what made you join the xml core wg? :-)
10:45
<annevk>
going to change their mind about xml:id? :p
10:45
<othermaciej>
that would be a boon to mankind
10:45
<hsivonen>
yes, please!
10:45
<zcorpan>
update xml-stylesheet
10:46
<zcorpan>
i guess i have to make opera drop support for xml:id before suggesting the wg drop it
10:48
<Hixie>
holy crap, you're giving xml-stylesheet the 5 treatment?
10:48
<Hixie>
that'd be awesome
10:49
<Hixie>
does that mean anne is going to do the cssom side too? :-)
10:49
<zcorpan>
Hixie: http://simon.html5.org/specs/xml-stylesheet5
10:50
Hixie
jumps into that spec and feels eerily familiar with a lot of the text :-P
10:50
<Lachy>
Hixie, re the list header thread, I was thinking the same thing but using an <h1> element instead. like <figure><h1>A header for the list</h1><ul><li>...</ul></figure>
10:50
<Lachy>
but I suppose <legend> is reasonable
10:51
<Hixie>
h1 would screw up the outline
10:51
<zcorpan>
Hixie: i wrote it from scratch! promise! :rolleyes:
10:51
<Lachy>
no, cause <figure> is a sectioning root, and the spec says it wouldn't
10:51
<Hixie>
unless they really wanted that, in which case <section> would be better than <legend>
10:51
<Hixie>
oh it is?
10:51
<Hixie>
sweet
10:51
<Hixie>
zcorpan: :-P
10:52
<Hixie>
zcorpan: re 3.1 Conformance constraints
10:52
<Lachy>
Hixie, could you make a note to add an example of this use case to the spec
10:52
<Lachy>
or I could send mail if you like
10:53
<Hixie>
zcorpan: it's unclear what those conformance requirements mean. are they well-formedness checks, or just conforamnce requirements that mean nothing except to any implement except henri?
10:53
<Hixie>
Lachy: file a bug or send mail, yes please
10:53
<Hixie>
Lachy: note that i just added it to the faq
10:53
<zcorpan>
Hixie: the latter
10:54
<Hixie>
zcorpan: section 4 explained it to me, yeah. a note in 3 would be helpful.
10:54
<zcorpan>
noted. thanks
10:54
<Hixie>
zcorpan: (in particular, because with xml, one never knows what is expected to be the end of the world and what should be ignored)
10:55
<Hixie>
zcorpan: (it wouldn't be a big deal if this was, say, css or html)
10:55
<Hixie>
man, i've really corrupted y'all
10:55
<Hixie>
this state machine feels eerily familiar!
10:56
<zcorpan>
lol
10:58
<Hixie>
"must stop the state machine so that pseudo-attributes can be processed" could be clearer, it wasn't obvious to me how important that sentence was (namely that it represents the "output" of the algorithm) on my first reading. I don't have a good suggestion for improving it though.
10:59
<Hixie>
btw, your <dfn> elements aren't styled, which makes understanding what terms are special harder than ideal
10:59
<zcorpan>
i switched to the w3c style sheet
11:00
<Hixie>
"the user agent must begin to download the resource" should probably be a "should", since there are numerous reasons why the UA might not actually download the resource
11:00
<Hixie>
e.g. the user is roaming on a different continent and style sheets cost $3 per byte
11:00
<annevk>
Hixie, for background="...", shouldn't it set background-image to "url(" absolute URL ")" ...
11:01
<Hixie>
er yes
11:01
<Hixie>
er well
11:01
<Hixie>
hm
11:01
<annevk>
CSS doesn't quite define the appropriate hooks I'm afraid
11:01
<Hixie>
yeah
11:01
<zcorpan>
Hixie: changed
11:03
<Hixie>
looks like a good spec overall
11:03
<Hixie>
you're going to need hooks into anne's non-existent (iirc) cssom draft
11:03
<Hixie>
e.g. to define how this hooks up to alternative style sheets
11:04
<annevk>
it does actually exist, but I haven't found time to work on it in the past year or so :/
11:04
<Hixie>
annevk: i'm going to leave it as setting it to hte URL, and claim that url(...) is a URL (and that a URL isn't a string)
11:04
<Hixie>
annevk: i know, i'm just teasing :-)
11:04
Hixie
finds that working on two drafts at a time is hard enough
11:05
jgraham
wishes he knew why his hard drive was spinning so much
11:05
<Hixie>
what OS?
11:05
<zcorpan>
Hixie: thanks
11:06
<hsivonen>
I believe annevk is right and Rob Burns isn't when it comes to Unicode normalization in a conforming XML processor
11:07
<jgraham>
Hixie: Linux (Ubuntu)
11:07
<Hixie>
jgraham: use lsof(1)
11:09
<annevk>
Hixie, http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#file-upload-state .value does apply to <input type=file> ...
11:11
<Hixie>
annevk: send mail
11:11
<Hixie>
or file a bug
11:11
<Hixie>
you're right, i should just make it apply with mode "filename" or some such
11:11
<annevk>
I'll file a bug
11:46
<Hixie>
i like how every browser supports font-size:xxx-large
11:51
<annevk>
I like how for filing spec bugs test cases are not a requirement
11:52
<annevk>
Hixie, Opera does not
11:53
<annevk>
Hixie, Firefox does not...
11:53
<Hixie>
hey look at that
11:53
<Hixie>
there's a bug in my testcase
11:53
<Hixie>
nevermind!
11:53
<Lachy>
Hixie, we have a bug about submitting forms to fragment identifiers. e.g. <form action="#top">. I can't figure out from the spec what the expected behaviour is supposed to be
11:54
<Hixie>
?
11:57
<Hixie>
per spec, the fragment identifier should have no effect
11:57
<Hixie>
(except for changing how the url is resolved)
11:57
<annevk>
though it should survive the request and potential redirects
11:57
<Hixie>
(in the presence of a <base> element, e.g.)
11:57
<Hixie>
yeah
11:59
<Lachy>
ok
12:01
<annevk>
oh great, Opera has a bug per HTML5 in font handling
12:01
<annevk>
<font size=+> is treated as a presentional hint
12:01
<Hixie>
really?
12:02
<annevk>
yeah, but not in e.g. Firefox
12:02
<Hixie>
oh yeah
12:02
<Hixie>
weird
12:02
<Hixie>
opera only
12:02
annevk
checks IE
12:02
<annevk>
yeah, Opera only
12:06
<annevk>
but hey, our behavior is conforming anyway :p
12:07
<Hixie>
conforming but "unexpected" :-)
12:17
<zcorpan>
Hixie: "The td and th elements' height attributes map to the dimension property 'height' on the element." is stated twice
12:18
<Hixie>
i removed a copy, i hope that was not a more serious error
12:25
<zcorpan>
Hixie: surely <div align=justify> should justify the text, not left-align?
12:25
<Hixie>
you'd think
12:25
<Hixie>
can you get IE to justify text?
12:25
<zcorpan>
just tested in opera and firefox
12:26
<zcorpan>
ie8
12:26
<zcorpan>
yep
12:26
<zcorpan>
also in quirks mode
12:28
<Hixie>
url?
12:29
<zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%0D%0A%3Cdiv%20align%3Djustify%3Eaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%20aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%20aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12:29
<annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3Dwidth%3A100px%20align%3Djustify%3Etest%20tes%20te%20st%20fdkjla%20fdalk%20fds%20fjd%20sfs%20afsd
12:30
<annevk>
same for IE6
12:31
<zcorpan>
i see it for <td> though
12:32
<zcorpan>
however opera, firefox and webkit justify for <td>
12:33
<zcorpan>
and i haven't seen pages break because of it
12:34
<zcorpan>
so i'd go with the majority :)
12:35
<zcorpan>
in fact, ie doesn't support 'justify' on tables at all
12:35
<zcorpan>
<table><tr align=right><td align=justify>foo bar
12:35
<zcorpan>
is right-aligned
12:36
<zcorpan>
(insert width=100% on the table tag)
12:36
<annevk>
ooh, did zcorpan just beat Hixie in a reverse engineering match? :D
12:37
<jgraham>
I guess Kixie is lining up for a killer blow :)
12:37
<jgraham>
*Hixie
12:37
<Hixie>
i was testing <div> inside <caption> primarily, iirc
12:40
<zcorpan>
justifies for me
12:40
<zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Ctable%20width%3D100%25%20border%3E%0D%0A%3Ccaption%20width%3D100%25%20style%3Dborder%3Asolid%3E%20%3Cdiv%20align%3Djustify%3Eaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%20aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%20aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
12:41
<Hixie>
i wonder what i was doing
12:41
<Hixie>
oh well
12:44
<Hixie>
fixed
12:45
annevk
changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks! -- zcorpan 1 : Hixie 0'
12:51
<Hixie>
ok tomorrow i begin on 10.4 Self-contained features
12:51
<zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cdiv%20align%3Dright%3E%0D%0A%20%3Ctable%20border%20style%3Dmargin-right%3Aauto%3E%3Ctd%3Ex
12:51
<Hixie>
feel free to send mail on 10.3 stuff
12:51
<Hixie>
i'm going to bed now
12:51
<Hixie>
nn
12:51
<zcorpan>
nn
12:52
<jgraham>
goodnight
13:02
<zcorpan>
hsivonen: http://www.456bereastreet.com/archive/200902/validating_wai-aria_in_html_and_xhtml/ - apparently roger wants html4+aria with landmarks, too
13:04
<hsivonen>
zcorpan: does at least one of Gecko/WebKit/Presto/Trident expose landmarks to AT?
13:05
<zcorpan>
hsivonen: there's no dedicated way to expose landmarks (yet), but gecko expose them as any other (unknown) role, i think
13:06
<zcorpan>
or maybe that has changed now, i haven't followed aria stuff closely lately; ask aaronlev
13:06
<hsivonen>
zcorpan: thanks
13:07
<zcorpan>
i am unaware of any browser+AT combination that does something useful with landmarks
13:07
<zcorpan>
but as i said i'm not on top of the topic :)
13:10
<annevk>
we need more spec minions
13:13
<hsivonen>
does anyone have concrete data that shows the necessity of autodetecting BOMless UTF-16?
13:14
<jgraham>
hsivonen: No, but define "necessity"
13:14
<hsivonen>
I want to avoid the problems that accidental detection as UTF-16 causes if at all possible
13:14
<annevk>
maybe for non-Western sites generated by PHP that do not declare an encoding but are using UTF-16? (PHP has issues with BOM)
13:15
<hsivonen>
jgraham: something that would be considered a regression that'd need fixing in Gecko
13:17
<hsivonen>
so far I know that if Chinese probabilities are loaded but Cyrillic probabilities aren't, bad stuff can happen on Cyrillic sites
13:19
<zcorpan>
got email from stevef: [[ supported in JAWS 10
13:19
<zcorpan>
detailed info
13:19
<zcorpan>
http://www.paciellogroup.com/blog/?p=106
13:19
<zcorpan>
http://www.paciellogroup.com/blog/misc/landmarks.html ]]
13:19
<hsivonen>
thanks
13:20
<hsivonen>
I don't like the way the implementation order of HTML5 intrinsic landmarks and ARIA landmarks played out, but I guess that's enough of a reason to stop trying to object to ARIA landmarks
13:20
<annevk>
not enough*
13:26
<Lachy>
hsivonen, would you have preferred implementers to get the HTML5 elements implemented first, reducing the need for aria landmarks at all?
13:26
<hsivonen>
Lachy: I'd have preferred HTML5 elements getting exposed as landmarks first and then not doing ARIA landmarks at all
13:27
<annevk>
agreed, that would have benefited authors as well
13:27
<Lachy>
yeah, that's basically what I argued for when the aria discussion started
13:37
<yecril71>
Attributes in XHTML are in the default namespace.
13:38
<annevk>
they are not in a namespace
13:38
<yecril71>
Therefore, xhtml:content would not refer to anything particular.
13:40
<yecril71>
All right, I should have rather used "global namespace" instead.
13:41
<yecril71>
List headers can be simulated using DL; I have updated the FAQ with an example.
13:41
<hsivonen>
yecril71: the right term is "in no namespace"
13:42
<hsivonen>
actually, "not in a namespace" as anne said is probably even more correct
13:43
<yecril71>
so getAttributeNS("content", "") should fail?
13:43
<hsivonen>
yecril71: "not in a namespace" is represented as null as the NS URI in the DOM
13:43
<hsivonen>
as the empty string in SAX
13:44
<yecril71>
so getAttributeNS("content", "") should fail?
13:44
<hsivonen>
yes
13:44
<yecril71>
Thx
13:46
<annevk>
getAttributeNS(null, "content") is the same as getAttributeNS("", "content") fwiw
13:46
<hsivonen>
oh
13:46
<yecril71>
Sorry for getting the parameters upside down :-(
13:47
<hsivonen>
annevk: is that a Web DOM thing or a W3C DOM thing?
13:47
<annevk>
hsivonen, W3C DOM aliases "" and null
13:48
<yecril71>
Is it possible to go out of namespace with xmlns attribute?
13:49
<yecril71>
(to leave the current namespace, that is)
13:51
<hsivonen>
yecril71: do you mean xmlns=""?
13:53
<yecril71>
I thought xmlns="" restores the global namespace.
13:53
<annevk>
there's no global namespace
13:53
<annevk>
that's XML 2.0 fiction
13:53
<yecril71>
Aha.
13:54
<yecril71>
So the effect is "no namespace", right?
13:55
<Philip`>
Is it something like xmlns="" or xmlns:foo="" that's forbidden in XML 1.0 but allowed in XML 1.1?
13:56
<yecril71>
xmlns:foo="" is forbidden.
13:56
<yecril71>
"The empty namespace must go unprefixed", MSXML says.
13:58
<Lachy>
yecril71, using a <dl> to simulate a list header doesn't seem semantically correct to me
13:59
<yecril71>
It is part of a larger paradigm, using DL to simulate a record.
14:00
<yecril71>
In JSON, it would go { apples: [ ... ] }
14:00
<annevk>
Philip`, it's xmlns:foo="" though there has been talk on lifting the restriction
14:01
<Philip`>
annevk: Lifting it in a new edition of XML 1.0?
14:01
<annevk>
of Namespaces in XML 1.0
14:02
<annevk>
the wording is not that good either currently "In such declarations, the namespace name may not be empty."
14:02
<annevk>
I think I raised that as an issue
14:02
Philip`
is being too lazy to write "Namespaces in" when he refers to it :-)
14:03
<yecril71>
It is not clear whether "name" refers to the prefix or to the URL.
14:03
<yecril71>
I would say it refers to the prefix because it is more like a name.
14:03
<annevk>
Philip`, actually, maybe it won't be changed, see NE14 in http://www.w3.org/XML/2006/xml-names-errata
14:04
Philip`
decides to not see NE14, since he's currently using Cygwin and it takes far too much effort to copy-and-paste a URL
14:09
Philip`
finds Minefield complaining that the Microsoft .NET Framework Assistant extension is incompatible, which is a bit confusing since he never installed that extension
14:10
<zcorpan>
whey, basefont?
14:10
<zcorpan>
why did Hixie spec basefont?
14:11
<zcorpan>
i thought we could get away with not supporting it
14:13
<annevk>
don't we support it?
14:14
<zcorpan>
no (iirc)
14:14
<zcorpan>
only ie supports it
14:14
<annevk>
afaict we do
14:14
<hsivonen>
in IE8 mode?
14:15
<annevk>
Firefox does not
14:17
<annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?x%3Cbasefont%20size%3D7%3E1%3Cfont%20size%3D%2B0%3ELARGE?%3C%2Ffont%3E
14:17
<annevk>
IE of course supports it in a way that is different from most browsers, it actually encloses elements
14:18
<annevk>
HTML5 does not support it in the IE way
14:18
<zcorpan>
oh we only support it for relative size on <font>
14:18
<zcorpan>
ok
14:19
<annevk>
what does WebKit do?
14:19
<zcorpan>
same as firefox
14:19
<annevk>
seems better to drop it then
14:20
<annevk>
going with something that's Opera compatible and not IE/Gecko/WebKit compatible is bound to be troubling
14:21
<zcorpan>
it's only not compatible with ie if people include </basefont>
14:21
<Lachy>
yikes! http://lists.w3.org/Archives/Public/www-archive/2009Feb/0029.html
14:21
<annevk>
in my testcase IE renders "1" very large as well
14:22
<annevk>
per HTML5 and Opera it should not
14:24
<zcorpan>
annevk: ok. i don't object to dropping it :)
14:25
<zcorpan>
Lachy: hmm, i don't see how the "mime type document" is in conflict with html5
14:29
<Lachy>
I don't know either
14:29
<hsivonen>
zcorpan: the mime type document encourages people to serve DOM Consistency-violating XHTML+RDFa docs as text/html
14:30
<zcorpan>
ah
14:31
<Lachy>
oh, wow. The old NOTE that I read didn't say anything about RDF
14:31
<zcorpan>
but that's more a problem of RDFa violating DOM Consistency
14:32
<hsivonen>
Lachy: the note tiptoes around RDFa without being too specific about it, but it you read carefully, it doesn't put RDFa in the same bucket as MathML
14:32
<Lachy>
hsivonen, the mime types draft says "In particular, 'text/html' is NOT suitable for XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML]."
14:32
<Lachy>
oh
14:32
<Lachy>
I havne't read it in detail. Maybe I will later
14:32
<hsivonen>
Lachy: well, the RDFa attributes themselves aren't from a foreign namespace
14:33
<hsivonen>
Lachy: xmlns:foo could be construed to be, but only in the DOM representation
14:33
<hsivonen>
s/DOM/XML DOM/
14:33
<hsivonen>
infoset-wise, one might argue that xmlns:foo slips past the qualification
14:34
<Lachy>
I suppose, technically, now it is in conflict with HTML5 because it says you can't use MathML in text/html, but now HTML5 says you can
14:34
<hsivonen>
well, that, too
14:36
<zcorpan>
when i commented on it, i mostly just tried to make the guidelines suck less
14:37
<zcorpan>
now they do suck less, but it's still possible to make harsh comments
14:37
<zcorpan>
maybe i should take a second pass someday
14:38
<hsivonen>
it might be that Dean sees a different conflict that I'm not noticing
14:40
<Lachy>
I'm not sure what problems Dean sees. I just think his approach to it, regardless of whether his concerns are valid or not, isn't the most constructive
14:41
<hsivonen>
I agree. but I can see how someone might get annoyed by a WG proceeding to publish without responding to feedback
14:46
<zcorpan>
they didn't address all my comments, i think
14:47
<annevk>
some of my 2004 or thereabouts comments on XHTML2 still stand as well
14:47
<zcorpan>
they said they'd fix my issues going forward
14:47
<zcorpan>
and i checked back sometime and they had fixed some things
14:47
<hsivonen>
zcorpan: and IIRC, initially it looked like some participant(s?) were willing to ignore all your comments
14:47
<zcorpan>
then suddenly it was published without them going back to me asking if the result was ok
14:47
<zcorpan>
hsivonen: pointer?
14:48
<hsivonen>
zcorpan: I'd have to wade through the telecon minutes
14:48
<hsivonen>
let's see if Google can do it for me
14:48
<zcorpan>
don't put too much effort into it :)
14:49
<hsivonen>
zcorpan: http://www.w3.org/2008/09/10-xhtml-minutes.html
14:49
<hsivonen>
"what is obligation - have to respond, but not address or satisfy all comments if cannot be satisfied?" "can we simply thank him?"
14:51
<zcorpan>
uh yeah
14:51
<zcorpan>
"you're welcome"
14:51
<zcorpan>
thanks
14:51
<zcorpan>
gotta go
14:55
<karlcow>
[09:52] <annevk> some of my 2004 or thereabouts comments on XHTML2 still stand as well
14:55
<karlcow>
annevk: same here, I still have a lot of unanswered comments, but I'm not requesting anything. :)
14:56
<karlcow>
Maybe I just react too strongly on the way people behave sometimes. :)
14:56
<hsivonen>
karlcow: do you have outstanding comments on drafts or on docs that exited their draft stage?
14:57
<annevk>
yeah, if they just published as WD it would've been different
14:58
<karlcow>
in 8 years, I think most of the comments I have done during last call have been answered. It has happened some of my comments have not been taken into account, but that's life. There's nothing wrong with that.
15:01
<karlcow>
for XHTML 2.0 specifically There are around 60 comments (from me) in the pipe
15:01
<hsivonen>
http://twitter.com/fantasai/statuses/1174794173
15:09
<Lachy>
I've just accepted the fact that I'm unlikely to ever get a response to the issues I raised against XHTML2 in 2004 and 2005, and now just ignore the work completely.
16:36
<gsnedders>
Hixie: Every word of the spec? Man, get a life!
16:36
<gsnedders>
:D
16:45
<jgraham>
gsnedders: 256526 words if I got it right
16:45
<jgraham>
(that seems rather long)
16:45
<gsnedders>
jgraham: Get a life too.
16:46
<jgraham>
gsnedders: If I had a life I would not have written html5lib and so that would not have been much an easy question to get the wrong answer to
16:46
<jgraham>
(er, I should say helped to write html5lib)
16:47
<jgraham>
(since other people did all the important and difficult bits)
16:47
<annevk>
really? I thought you did the difficult bits
16:47
<annevk>
at least when we started out :)
16:49
<jgraham>
annevk: Well Philip` has rewritten all the entity decoding stuff at leasst once
16:50
<jgraham>
Which is important and difficult :)
16:50
gsnedders
has a broken implementation of that
16:50
<gsnedders>
Out of date, too
16:53
jgraham
hopes that Philip` only has UCS4 builds of python because the patch to get the right number of errors in the tokenizer for non-BMP characters will be slooow
17:13
<annevk>
did zcorpan comment on public-html regarding multicol and spacer not needing display:block ?
17:17
<annevk>
surely "table[XXX] > tr > td" is not needed for legacy content
17:45
<zcorpan>
annevk: i didn't
17:47
<annevk>
you can thank me then :p
17:48
<zcorpan>
thank you
17:49
<zcorpan>
wait, will i have to attend to telecons?
17:49
<zcorpan>
i'm already having second thoughts about this
17:49
<annevk>
XML Core WG?
17:49
<zcorpan>
yeah
17:50
<annevk>
just explain them your idea and ask whether it can be done without attending telcons
18:34
<takkaria>
playing with canvas is actually quite fun
22:00
<Lachy>
I don't recall Firefox 2's parser creating a fieldset element when it saw a legend element outside of one. I wonder why that would have been introduced in Firefox 3
22:08
<Hixie>
pretty sure ff2 did it too
22:16
<Lachy>
oh, you're right. It does do it. It's odd that I wasn't aware of that behaiour
22:19
<gsnedders>
Oh, yeah, if you get caught having a spy plant a nuke in Civ2 everyone declares war on you. I forgot that.
22:28
<Lachy>
gsnedders, what?
22:28
<gsnedders>
Lachy: Nothing
22:30
<Lachy>
gsnedders, it's just that what you said is even more ambiguous than some of your tweets
22:30
<Lachy>
oh, that was one of your tweets :-)
22:59
<takkaria>
conway's game of life with canvas, looking quite cool:
22:59
<takkaria>
http://takkaria.org/life.html
23:01
<ehird>
nice, but...
23:01
<ehird>
life cells don't "fade away" :_0
23:01
<ehird>
*:-)
23:02
<ehird>
takkaria: "Randomise' doesn't work
23:03
<inimino>
wfm
23:04
<inimino>
nice demo
23:04
<ehird>
inimino: what browser?
23:04
slightlyoff
notes that this could easily be done w/ a <table> or positioned <div>'s
23:04
<inimino>
firefox trunk
23:05
<ehird>
slightlyoff: yeah, if you want to wait until the heat death of the universe to watch a glider gun
23:05
<slightlyoff>
ehird: ??
23:05
<ehird>
slightlyoff: they're sloooooooow to update.
23:05
<slightlyoff>
ah, so this only looks right on FF
23:05
<slightlyoff>
(webkit nightlies don't do the fading)
23:05
<ehird>
ahhh
23:06
ehird
tries FF
23:06
<ehird>
It's slower now, but actually works.
23:06
<ehird>
That is a plus.
23:06
<slightlyoff>
also busted on chrome
23:07
<slightlyoff>
looks right on opera
23:08
<ehird>
Setting fade rate = 1 makes it actually correct Life.
23:08
<slightlyoff>
(but the slider is busted there)
23:08
<ehird>
It's certainly doing *something* on WebKit, but it's not Life.
23:08
<slightlyoff>
ehird: heh
23:10
<inimino>
Life finds a way?
23:45
<Hixie>
i hate that <applet> starts with an "a"
23:45
<Hixie>
it means that all alphabetical lists of embedded content elements start with an obsolete element.
23:46
<roc>
I've figured out what this normalization debate is about
23:47
<roc>
people want browsers to handle normalization, instead of other parts of the toolchain, because browsers "have to" obey Web standards and other tools don't
23:51
<Hixie>
heh
23:52
<othermaciej>
what normalization debate is this?
23:54
<Hixie>
ww-style