2007-06-01
[18:16:00.0000] <zcorpan_>
Hixie: http://www.ietf.org/rfc/rfc4329.txt

[18:21:00.0000] <Hixie>
oh is that what he was referring to

[18:21:01.0000] <Hixie>
interesting

[19:02:00.0000] <Hixie>
is "01/01/1970 00:00:00" any sort of standard date format?

[19:05:00.0000] <gavin>
mysql DATETIME?

[19:05:01.0000] <Hixie>
hm

[19:05:02.0000] <gavin>
hmm, no I guess that uses dashes, not slashes

[19:05:03.0000] <Hixie>
i was hoping for some RFC or something

[19:05:04.0000] <Hixie>
oh well

[19:05:05.0000] <Hixie>
it's not a format i recognise as being standard

[19:05:06.0000] <Hixie>
(it's the format document.lastModified uses)

[19:13:00.0000] <zcorpan_>
new Date() return slightly different things in opera vs firefox/ie7

[19:13:01.0000] <zcorpan_>
opera has a comma after the weekday

[19:14:00.0000] <zcorpan_>
firefox/ie7 don't

[19:14:01.0000] <Hixie>
nice

[19:14:02.0000] <zcorpan_>
or well, there are more differences actually

[19:15:00.0000] <zcorpan_>
Fri Jun 1 03:23:36 UTC+0200 2007 (ie7)

[19:16:00.0000] <gavin>
hmm, we changed the format for lastModified Firefox 1.5

[19:16:01.0000] <gavin_>
https://bugzilla.mozilla.org/show_bug.cgi?id=99224

[19:16:02.0000] <Hixie>
does it match what i put in teh spec?

[19:16:03.0000] <gavin_>
-    CopyASCIItoUCS2(NS_LITERAL_CSTRING("January 1, 1970 GMT"), aLastModified);

[19:16:04.0000] <gavin_>
+    aLastModified.Assign(NS_LITERAL_STRING("01/01/1970 00:00:00"));

[19:16:05.0000] <zcorpan_>
Fri Jun 01 2007 03:23:44 GMT+0200 (firefox)

[19:16:06.0000] <zcorpan_>
Fri, 01 Jun 2007 03:23:47 GMT+0200 (opera)

[19:16:07.0000] <gavin_>
the person who changed it didn't change the comment that said "match what ns4.x returned", though :(

[19:17:00.0000] <Hixie>
so yes

[19:19:00.0000] <gavin_>
it looks like they were just trying to match IE

[19:20:00.0000] <zcorpan_>
yeah. opera returns January 1, 1970 GMT

[19:20:01.0000] <gavin_>
https://bugzilla.mozilla.org/show_bug.cgi?id=107445#c6

[19:22:00.0000] <yod>
# # [03:23] <Hixie> it's so sad seeing the w3c validator team try to make itself irrelevant  

[19:22:01.0000] <yod>
how is listening to the decision of the WG in charge "making itself irrelevant"?

[19:22:02.0000] <yod>
or maybe the problem is that this WG is disagreeing with you?

[19:23:00.0000] <yod>
thinking like GW Bush is not making the web a favour, you know...

[19:23:01.0000] <Hixie>
the problem is the WG agreeing with the rest of the planet, and the validation team following them blindly

[19:24:00.0000] <Hixie>
but luckily we have the html wg now, and the html wg is defining this sanely, so the issue is moot

[19:24:01.0000] <yod>
then why the insulting comment?

[19:24:02.0000] <Hixie>
which part is insulting?

[19:25:00.0000] <yod>
"try to make itself irrelevant"

[19:25:01.0000] <Hixie>
that's not insulting, that's descriptive

[19:25:02.0000] <Hixie>
olivier decided to not fix a bug, because the htmlwg contradicted itself and olivier thought it wiser to follow them than to help the validator's users

[19:26:00.0000] <yod>
I'm olivier, BTW :)

[19:26:01.0000] <Hixie>
oh. well then i spoke to you just the other day on #html-wg about this.

[19:26:02.0000] <yod>
and I agreed with you

[19:26:03.0000] <yod>
on some of the issues

[19:27:00.0000] <yod>
but it doesn't change the fact that the xhtml WG is in charge of xhtml, and that the validator is supposed to follow what rules they set

[19:27:01.0000] <Hixie>
they haven't set any actual rules here. they have just made two contradictory non-normative statements.

[19:27:02.0000] <othermaciej>
the xhtml2 WG is not in charge of the text/html MIME type

[19:28:00.0000] <othermaciej>
but I'll agree the text/html media type is currently quite poorly specified

[19:28:01.0000] <Hixie>
othermaciej: the validator is claiming (as i understand it) that its not a text/html validator, it's an html4 and xhtml1 validator

[19:28:02.0000] <Hixie>
over which the xhtml2 wg does claim ownership

[19:30:00.0000] <zcorpan_>
does anyone have a pointer to any of this?

[19:31:00.0000] <zcorpan_>
/me doesn't follow what is being discussed

[19:32:00.0000] <Hixie>
http://krijnhoetmer.nl/irc-logs/whatwg/20070531#l-82

[19:33:00.0000] <karlUshi>
/me thinks that some people would have better behavior in physical meetings than other IRC. 

[19:43:00.0000] <zcorpan_>
Hixie: "Note: The dir attribute on the HTMLDocument interface is defined along with the dom content attribute." -- there is a "dom" content attribute?

[19:44:00.0000] <Hixie>
oops

[19:51:00.0000] <zcorpan_>
Hixie: btw, you may need to spec document.embeds too

[19:52:00.0000] <Hixie>
you know the drill -- send mails ;-)

[19:53:00.0000] <zcorpan_>
yup :)

[23:23:00.0000] <hsivonen>
Hixie: where do you keep your character encoding tests?

[23:23:01.0000] <hsivonen>
Hixie: are they somewhere on damowmow? can't find them on hixie.ch

[23:25:00.0000] <Hixie>
which ones?

[23:25:01.0000] <Hixie>
you mean smontagu's?

[23:25:02.0000] <Hixie>
smontagu.damowmow.com?

[23:25:03.0000] <hsivonen>
Hixie: IIRC you had some tests when you wrote the encoding sniffing section

[23:26:00.0000] <Hixie>
that'll be in hixie.ch/tests somewhere

[23:26:01.0000] <hsivonen>
Hixie: looks like smontagu's tests are what I was about to write. thanks

[23:27:00.0000] <hsivonen>
http://www.hixie.ch/tests/adhoc/html/parsing/encoding/ looks like it

[23:28:00.0000] <hsivonen>
nah. smontagu's tests lack the C1 range which is what I am interested in

[01:42:00.0000] <hendry>
am I right in claiming that in some Web designs, that if the font the Web designer used in his design isn't availible and another one is substituted the design can really mess up?

[01:42:01.0000] <hendry>
like overlapping text et al?

[01:42:02.0000] <Hixie>
overlapping text shouldn't happen unless the designer in question didn't use 'em' units (e.g. setting line-height in px)

[01:43:00.0000] <hendry>
Hixie: right

[01:43:01.0000] <hendry>
though pixel based designs are all too common

[01:43:02.0000] <hendry>
http://flickr.com/photos/hendry/521334985/ # e.g. of overlapping text

[01:51:00.0000] <mikeday>
just means you need to install as many fonts as possible, starting with the Microsoft ones

[01:52:00.0000] <hendry>
mikeday: ah that's a solution I'm trying to avoid :)

[01:53:00.0000] <hendry>
http://natalian.org/archives/2007/05/31/chinese-font/

[01:53:01.0000] <hendry>
for example the ms corefonts don't quite exist in CJK markets

[01:54:00.0000] <mikeday>
the other option is to hire a typographer to design fonts that match the metrics of the Microsoft fonts

[01:54:01.0000] <mikeday>
just as the Microsoft fonts were designed to match Times/Helvetica/Courier :)

[01:55:00.0000] <mikeday>
by the way, DejaVu looks likes Vera 'cos it's designed from Vera

[01:55:01.0000] <mikeday>
part of the license agreement for Vera is that you have to change the name if you modify it.

[01:57:00.0000] <mikeday>
Oops, looks like Red Hat is already doing that

[01:57:01.0000] <mikeday>
"Red Hat contracted with Ascender Corp., one of the leading commercial developers of fonts, to develop a set of fonts that are metrically equivalent to the key Microsoft fonts."

[01:58:00.0000] <mikeday>
https://www.redhat.com/promo/fonts/

[02:01:00.0000] <hsivonen>
hendry: in the case of DejaVu, adding glyphs to Vera as an open source project seems to work

[02:03:00.0000] <hendry>
hsivonen: could you add that as a comment? Or should I re-edit my rant? :)

[02:04:00.0000] <hendry>
mikeday: aha

[02:04:01.0000] <hendry>
mikeday: i also must add that info to the blog entry

[02:07:00.0000] <jruderman>
i hope that isn't a font called "Serif". that would screw with http://www.w3.org/TR/CSS21/fonts.html#serif-def

[02:07:01.0000] <hendry>
hsivonen: ok, i have updated the blog entry, so no need to comment

[02:27:00.0000] <mikeday>
Having a font called "Serif" is a bit silly, but I think in this case it is supposed to be "Liberation Serif"

[02:27:01.0000] <mikeday>
"Libre" would be a better name I think, but you'd need an accent on the e and that might confuse people :)

[02:31:00.0000] <Dashiva>
Hixie: scrollIntoView says scrolling the document into view (instead of the element) in r852, parameter=true case

[06:11:00.0000] <hsivonen>
Hixie: why deus the meta charset algorithm continue if the charset name is unsupported? That seems weird. Is it what browsers do?

[06:11:01.0000] <hsivonen>
s/deus/does/

[08:23:00.0000] <krijnh>
annevk: verslaafde ;)

[08:28:00.0000] <annevk>
hehe

[12:51:00.0000] <annevk>
Questions today: does HTML5 provide more trivial shorthands for doing asynchronous requests (I showed the Google suggest code)?

[12:52:00.0000] <annevk>
Others have been asked before: how does <section> work combined with <h1> - <h6>, when will it be done, when will it be implemented, etc.

[12:57:00.0000] <annevk>
http://www.webdevout.net/tidings/2007/05/22/self-contradictions-in-the-html-wg/

[13:08:00.0000] <om_food>
annevk: did you see my datalist trick for doing an "ajax combobox" with basically two lines of html5 code?

[13:09:00.0000] <othermaciej>
(not sure if these are your questions or someone else's)

[13:10:00.0000] <annevk>
<input list=foo oninput="list.data = '?p' + encodeURIComponent(value)"><datalist id=foo></datalist> ?

[13:10:01.0000] <othermaciej>
yes

[13:10:02.0000] <annevk>
yeah, I showed that one

[13:10:03.0000] <othermaciej>
the template thing Hixie and hyatt are working on would be even more general

[13:10:04.0000] <annevk>
I think people want more of where that came from :)

[13:11:00.0000] <annevk>
kk

[13:11:01.0000] <othermaciej>
and I think <datagrid> can also have an external data source

[13:56:00.0000] <hsivonen>
/me wonders why the charset meta sniffing algorithm bothers to upper-case attribute values

[14:11:00.0000] <hsivonen>
lower-case that is

[14:15:00.0000] <Hixie>
it compares one of the attribute values, no?

[14:18:00.0000] <Hixie>
gotta love people who admit that the use cases are extremely rare but STILL want the feature

[14:21:00.0000] <gsnedders>
can we have every accessibility feature possible, regardless of the size of the use case?

[14:27:00.0000] <Dashiva>
What if we have invisible aliens who interact through sandpaper rasping sounds

[14:28:00.0000] <annevk>
There are probably simpler cases that are not addressed :)

[14:32:00.0000] <hsivonen>
Hixie: yeah, it says "If the next six characters are not 'charset'"

[14:33:00.0000] <hsivonen>
Hixie: is continuing when the tentative encoding is unknown the current browser behavior?

[14:34:00.0000] <hsivonen>
(sorry if you answered already and the answer slipped by my scrollback)

[14:35:00.0000] <hsivonen>
Hixie: is it intentional that the sniffing algorithm talks about supported encodings and not supported *rough ASCII superset* encodings?

[14:38:00.0000] <othermaciej>
one quirk in Safari is that if there's a meta tag claiming the source is utf-16, we treat it as utf-8

[14:38:01.0000] <annevk>
is that a bug or actually needed?

[14:38:02.0000] <hsivonen>
othermaciej: is that a bug that stuck or is it needed by content out there?

[14:39:00.0000] <othermaciej>
(that's assuming there was no content-type header claiming otherwise)

[14:39:01.0000] <Dashiva>
If it's utf-16, it wouldn't be able to decode using the ascii process, right?

[14:39:02.0000] <othermaciej>
hsivonen: there is content that needs it

[14:39:03.0000] <othermaciej>
and if it was really utf-16, you wouldn't have found the meta tag

[14:39:04.0000] <annevk>
got to love the web

[14:40:00.0000] <hsivonen>
othermaciej: ok. what about UTF-32? :-)

[14:41:00.0000] <Dashiva>
The new scrollIntoView says to scroll the -document- into view for the true case. Am I right in seeing that as an error?

[14:42:00.0000] <Hixie>
hsivonen: dunno, haven't really looked into it recently. probably need to fix things up in the spec.

[14:43:00.0000] <annevk>
fyi: I heard lots of people complain about the charset finding byte algorithm

[14:43:01.0000] <othermaciej>
hsivonen: I think we may treat any claimed unicode charset in a <meta> tag as utf-8

[14:44:00.0000] <hsivonen>
othermaciej: ok

[14:44:01.0000] <hsivonen>
/me sends an email to get this on record

[14:44:02.0000] <othermaciej>
(I think maybe same for xml declarations)

[14:44:03.0000] <annevk>
Why would people write UTF-8 and then claim it's UTF-32?!

[14:45:00.0000] <hsivonen>
othermaciej: that would be dirty and very un-XML :-)

[14:45:01.0000] <othermaciej>
annevk: because Win IE handles it?

[14:45:02.0000] <othermaciej>
hsivonen: maybe we just reject such cases for XML, I dunno

[14:45:03.0000] <Hixie>
annevk: any specific complaints?

[14:47:00.0000] <othermaciej>
actually we do hack it for xml declarations

[14:47:01.0000] <othermaciej>
    if (source == EncodingFromMetaTag || source == EncodingFromXMLHeader || source == EncodingFromCSSCharset)

[14:47:02.0000] <othermaciej>
        m_decoder.reset(encoding.closest8BitEquivalent());

[14:47:03.0000] <annevk>
Hixie, the English algorithm was more complex than the implementation, for one

[14:48:00.0000] <annevk>
Hixie, hsivonen mentioned earlier that the algorithm "encouraged" look-ahead

[14:48:01.0000] <othermaciej>
closest8BitEquivalent currently only translates UTF16 (including BE and LE variants) to UTF-8

[14:48:02.0000] <annevk>
I believe jgraham had some thoughts about it as well, but I don't recall them

[14:48:03.0000] <Hixie>
annevk: ah, yeah, it's not as close to an implementation as the parser

[14:49:00.0000] <Hixie>
annevk: mostly because i didn't implement it :-)

[16:22:00.0000] <Philip`>
"If the next six characters are not 'charset'" - isn't that seven characters?

[16:38:00.0000] <Hixie>
arguably, yes

[16:38:01.0000] <Hixie>
i mean, if you insist on precise numerical counting accuracy

[16:38:02.0000] <Hixie>
send mail :-)

[16:38:03.0000] <kingryan>
Hixie: you were counting from 0, right?

[16:39:00.0000] <Hixie>
kingryan: i think even i would have trouble arguing that "charset" has length 6. :-)

[16:39:01.0000] <Hixie>
kingryan: otherwise, how long is the empty string? :-)

[16:39:02.0000] <kingryan>
there is no empty string

[16:39:03.0000] <kingryan>
/me waves hands

[16:39:04.0000] <Hixie>
hah

[16:40:00.0000] <kingryan>
Math5

[16:40:01.0000] <kingryan>
to go with HTML5


2007-06-02
[17:23:00.0000] <zcorpan_>
annevk: did you get your t-shirt?

[19:50:00.0000] <kfish>
moin

[19:50:01.0000] <kfish>
is there any way to specify the authorship / authority of subparts of a web page?

[19:51:00.0000] <kfish>
s/is there/are there any proposals for/

[19:51:01.0000] <zcorpan_>
<address>?

[19:51:02.0000] <kfish>
eg. if i wanted to say that the comments section of a web page was not authored by the site, could contain public comments ie. spam

[19:52:00.0000] <kfish>
basically, to set a nofollow attribute to an element

[19:52:01.0000] <zcorpan_>
use rel=nofollow on the links

[19:53:00.0000] <kfish>
cheers :-)

[19:54:00.0000] <zcorpan_>
using an outer <article> for the main post and nested <article>s for the comments would indicate that the inner articles were actually comments

[20:18:00.0000] <MikeSmith>
kfish - you on mixi?

[20:18:01.0000] <MikeSmith>
http://mixi.jp/show_friend.pl?id=299825 is me

[20:20:00.0000] <kfish>
MikeSmith, nice taste in music :-)

[20:20:01.0000] <kfish>
yeah cool, just sent you an invite

[20:23:00.0000] <MikeSmith>
you can join my 全日本酔払い連合 community

[20:23:01.0000] <MikeSmith>
All Japan Drunkard Association

[20:27:00.0000] <kfish>
hahaha :-)

[01:25:00.0000] <annevk>
zcorpan_, yeah

[01:26:00.0000] <zcorpan_>
annevk: did you wear it at reboot?

[01:26:01.0000] <annevk>
no :(

[01:27:00.0000] <zcorpan_>
ok

[01:45:00.0000] <annevk>
lol

[01:45:01.0000] <annevk>
the last e-mail about headers= is so confused

[01:45:02.0000] <annevk>
trying to read all kinds of silly meaning out of the HTML4 specification...

[02:02:00.0000] <hsivonen>
annevk: FWIW, in angels-on-heads-of-SGML-pins discussions one might claim that #IMPLIED attributes are magically there. In Web reality, of course, an attribute can be present or not present in the DOM.

[02:06:00.0000] <annevk>
hmm, I was afraid of that

[02:07:00.0000] <othermaciej>
I think it makes more sense to distinguish absent attribute from attribute set to default value

[02:07:01.0000] <othermaciej>
(not that my opinion has much relevance)

[02:07:02.0000] <annevk>
yeah, you're an implementor

[02:07:03.0000] <annevk>
go away!

[02:07:04.0000] <annevk>
oh wait

[02:08:00.0000] <hsivonen>
part of the problem is that SGML and Web have a different notion of what a default value is

[02:09:00.0000] <hsivonen>
in SGML the parser reports it. on the Web, the default isn't in the DOM but the implementation reading the DOM uses the defaults if stuff isn't in the DOM

[02:09:01.0000] <annevk>
if people could just accept that "the Web" and not "SGML-based HTML4" is the where we are starting from...

[02:09:02.0000] <othermaciej>
my opinion on what works or doesn't may be well-informed, my opinion on what makes sense is as arbitrary as anybody's

[02:09:03.0000] <annevk>
<div contenteditable> and <div> are quite different for instance

[02:10:00.0000] <othermaciej>
empty vs. null

[02:11:00.0000] <annevk>
yeah, in the new-world getAttribute() terms :)

[02:11:01.0000] <hsivonen>
annevk: is there a new-world getAttribute() now? the old-world getAttribute() is definitely influenced by SGML thinking

[02:12:00.0000] <hsivonen>
/me hasn't done enough JS DOM work lately: world view influenced by Java DOM

[02:12:01.0000] <othermaciej>
someone needs to make a DOM Core spec that's useful for browsers

[02:12:02.0000] <annevk>
getAttribute() returns null if no attribute is specified

[02:12:03.0000] <annevk>
as opposed to the empty string which is required by the DOM spec

[02:13:00.0000] <hsivonen>
annevk: cool.

[02:13:01.0000] <hsivonen>
/me has written a bug in Java assuming the intuitive behavior when the library implemented the spec

[02:15:00.0000] <hsivonen>
/me wonders why the Java API designers assume that for character decoding I want to either recover from errors silently or treat them in a Draconian way but they don't offer reported recovery

[02:31:00.0000] <Lfe>
i just found out about navigator.onLine.. it will work out quite nicely with google gears :)

[02:32:00.0000] <annevk>
Lfe, yeah, in due course the ideas of Google Gears should be integrated with the rest of the APIs I think

[02:33:00.0000] <Lfe>
annevk: i agree. that's the kind of thing that needs to be "standardized" in order to work nicely

[02:33:01.0000] <othermaciej>
there's already a SQL API in the spec, but the offline caching API needs to be worked out

[02:33:02.0000] <othermaciej>
and reconciled with what Mozilla did

[02:33:03.0000] <annevk>
and there are these worker thread APIs

[02:33:04.0000] <othermaciej>
/me is a bit disappointed in Moz for not going to standards with their stuff sooner

[02:33:05.0000] <othermaciej>
the worker thread APIs are the simplest part

[02:33:06.0000] <othermaciej>
but also kinda the least useful

[02:34:00.0000] <annevk>
and you had some ideas about integrating persistent storage with the SQL stuff right?

[02:34:01.0000] <othermaciej>
well, just a throwaway suggestion

[02:34:02.0000] <othermaciej>
maybe there is a better way to integrate

[02:35:00.0000] <othermaciej>
but it bugs me that in the spec they are completely separate

[02:35:01.0000] <annevk>
otoh, the globalStorage stuff can go from key / value to key / object

[02:35:02.0000] <annevk>
so you can store arbitrary DOM objects and such

[02:37:00.0000] <annevk>
I suppose SVGDocument.title can just be dropped...

[02:37:01.0000] <othermaciej>
I don't see how storing an arbitrary DOM node could possibly give sensible results

[02:37:02.0000] <othermaciej>
or even storing a function

[02:37:03.0000] <othermaciej>
(you could stringify, then they it's just a dumb key / value pair)

[02:38:00.0000] <annevk>
you could store E4X objects or a Document which you can use as XML database

[02:39:00.0000] <othermaciej>
storing a Node can't preserve identity, which in the case of DOM objects makes a difference

[02:39:01.0000] <othermaciej>
unlike strings

[02:39:02.0000] <othermaciej>
if you store an element that's in the document and has children, when you come back to that doc later and retrieve it, it won't still be in the document

[02:40:00.0000] <othermaciej>
so if you save nodes, you get the equivalent of serializing / deserializing markup anyway

[02:41:00.0000] <annevk>
oh, you mean they become detached?

[02:41:01.0000] <othermaciej>
well, it can't preserve identity across document reloads

[02:41:02.0000] <annevk>
that seems fine

[02:41:03.0000] <othermaciej>
that just can't work

[02:41:04.0000] <annevk>
it's just that the browser does the serializing for you

[02:41:05.0000] <othermaciej>
yeah but it's also not any more useful than storing strings

[02:42:00.0000] <hsivonen>
annevk: considering how the DOM is implemented, storing DOM nodes seems like a huge pain

[02:42:01.0000] <othermaciej>
basically you're asking it to store .innerHTML instead of .toString()

[02:42:02.0000] <Lfe>
regarding the ManagedResourceStore.checkForUpdate() (how one should attain updated data) - gears seems to do a HTTP GET and compare mydata.currentVersion to the localized version string. Why not use HTTP HEAD / etag for this?

[02:42:03.0000] <Lfe>
(or similar techniques)

[02:42:04.0000] <othermaciej>
HTTP HEAD is broken enough to be useless in practice

[02:42:05.0000] <hsivonen>
annevk: if I stick some random function objects onto a C++-backed DOM node, what would you store?

[02:43:00.0000] <annevk>
hmm

[02:43:01.0000] <annevk>
at some point Hixie defined it

[02:44:00.0000] <annevk>
but removed it based on feedback from Mozilla (too much work iirc)

[02:44:01.0000] <hsivonen>
annevk: doing an XHR-like save operation to a local store would be a lot simpler that JS/C++ object serialization

[02:44:02.0000] <othermaciej>
serliazing JavaScript functions in a way that round trips properly is nearly impossible

[02:44:03.0000] <Lfe>
othermaciej: isn't that up to the host to "solve"? a head/etag would save lots of potential kb's 

[02:45:00.0000] <hsivonen>
othermaciej: mmap :-)

[02:46:00.0000] <othermaciej>
hsivonen: the hard part is handling captured scope - there's no clearly right way to restore it across exit and subsequent reload

[02:47:00.0000] <Lfe>
ah, manifestUrl != resourceUrl

[02:55:00.0000] <Lfe>
othermaciej: powernap?

[02:56:00.0000] <othermaciej>
Lfe: no, saw something on another channel that caught my eye

[03:43:00.0000] <annevk>
Shouldn't dir= default to something at some point?

[03:43:01.0000] <annevk>
Say, ltr for the root element...

[08:09:00.0000] <gsnedders>
apparently unit tests can avoid the need for an XML serialiser.

[08:09:01.0000] <gsnedders>
(when it comes to creating well-formed XML)

[09:00:00.0000] <Jero>
question: when the input stream is just "<html>", how are, according to the tree construction algorithm, the <head> and <body> elements created?

[09:01:00.0000] <annevk>
the current tree construction algorithm is not entirely correct as far as that goes

[09:02:00.0000] <Jero>
ah i see

[09:02:01.0000] <annevk>
html5lib is :)

[09:02:02.0000] <Jero>
so html5lib does stuff that isn't in the spec ATM to create those two elements??

[09:02:03.0000] <Jero>
ok :p

[09:03:00.0000] <Jero>
and do you think those steps will eventually be added to the spec?

[09:03:01.0000] <annevk>
we also removed the insertion mode switch

[09:03:02.0000] <Jero>
or is it just temporarily?

[09:03:03.0000] <annevk>
and made it all phases

[09:03:04.0000] <annevk>
the spec will be fixed, yes

[09:04:00.0000] <gsnedders>
some sites depend on it, so it does need to be fixed

[09:05:00.0000] <Jero>
annevk: yeah, I noticed html5lib does it differently than the spec

[09:05:01.0000] <Jero>
will that also be changed in the spec?

[09:05:02.0000] <annevk>
the spec has a note to that effect at the moment

[09:05:03.0000] <gsnedders>
Jero: html5lib's deviations are for compatibility with the web, so yes

[09:06:00.0000] <annevk>
but if Hixie decides to write the same thing down in some other way... so be it

[09:09:00.0000] <Jero>
okay, but the output of html5lib is still compatible with the spec i assume, even though it changed the steps to process the token?

[09:09:01.0000] <annevk>
it's mostly equivalent

[09:09:02.0000] <Jero>
oh ok, than it doesn't really matter

[09:09:03.0000] <Jero>
bedankt :)

[16:05:00.0000] <hsivonen>
annevk: is the diff between the spec and html5lib documented?


2007-06-03
[01:22:00.0000] <annevk>
hsivonen, a little bit

[01:38:00.0000] <met_>
hsivonen: found 2 years old czech validator (or conformance checker) based on relax schema, if you are intrested http://relaxed.vse.cz/relaxed/validate

[01:39:00.0000] <met_>
there is whole thesis available, but only in czech http://relaxed.sourceforge.net/thesis_cz.html

[01:40:00.0000] <met_>
see http://relaxed.sourceforge.net/

[01:47:00.0000] <met_>
oh quoted it in your thesis, ok 8-)

[05:06:00.0000] <gsnedders>
apparently you can't use SAX for a serialiser now.


2007-06-04
[04:36:00.0000] <maikmerten>
meh, Firefox hates me and won't load http://www.whatwg.org/specs/web-apps/current-work/#video

[04:36:01.0000] <annevk>
you can always try http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video

[04:40:00.0000] <maikmerten>
hmmm... that works

[04:41:00.0000] <maikmerten>
somehow my Firefox 2 (plain vanilla what comes with Ubuntu 7.04 plus a few extensions) is picky at times. It often gets into a "no, I won't load pages for you anymore until you kill and restart me" state

[04:42:00.0000] <maikmerten>
could be a profile issue, this profile may date back into Firefox alpha days ;)

[04:42:01.0000] <maikmerten>
err.. Phoenix alpha builds of course

[04:44:00.0000] <maikmerten>
I'm going to propose that http://wiki.xiph.org/index.php/OggPlayJavascriptAPI perhaps should be as close to the WHATWG API as possible

[04:45:00.0000] <met_>
annevk: what are reasons for XML5?

[04:45:01.0000] <met_>
it's only academic project or something more?

[04:46:00.0000] <met_>
oh www.xml5.com

[04:48:00.0000] <zcorpan>
http://code.google.com/p/xml5/

[04:48:01.0000] <annevk>
it might be worth something actually

[04:48:02.0000] <annevk>
ah, Phoenix!

[04:49:00.0000] <annevk>
/me wondered about the third name for some time

[04:49:01.0000] <zcorpan>
was it phoenix -> firebird -> firefox?

[04:49:02.0000] <annevk>
maikmerten, they are already implementing support for Ogg and <video> in Firefox

[04:49:03.0000] <annevk>
zcorpan, yeah

[04:50:00.0000] <met_>
worth something? do you think  webbrowsers will implement it?

[04:50:01.0000] <annevk>
maybe

[04:50:02.0000] <annevk>
dunno

[04:50:03.0000] <annevk>
it would certainly solve some issues

[04:51:00.0000] <met_>
so you are only playing with and will see the results later?

[04:51:01.0000] <met_>
/me just writing some article and want mention xml5

[04:52:00.0000] <maikmerten>
annevk, yup, Chris Double is working on that

[04:52:01.0000] <annevk>
I'm doing research into it and making a draft proposal as well as an experimental implementation

[04:52:02.0000] <annevk>
maikmerten, doesn't that make the plugin effort kind of pointless?

[04:52:03.0000] <annevk>
(which is what I was after)

[04:52:04.0000] <maikmerten>
annevk, well, I consider the plugin more or less a testbed for liboggplay

[04:53:00.0000] <maikmerten>
annevk, plus Chris mentioned he may look into the plugin/liboggplay to see if some things can be harvested

[04:53:01.0000] <annevk>
guess I should read up on liboggplay

[04:54:00.0000] <annevk>
hsivonen, I think UTF-32 is part of the deal

[04:54:01.0000] <maikmerten>
well, it's mostly a lightweight top-level abstraction library to play back Ogg streams in a sane way. It also handles A/V sync, which is nontrivial to do crossplatform

[04:56:00.0000] <annevk>
thans

[04:56:01.0000] <maikmerten>
only problem I see for use in browsers: It depends on libfishsound (abstraction layers for the multitude of Ogg audio codecs.... Speex, FLAC, Vorbis...) and on liboggz (abstraction layer for libogg, which is the very opposite of high-level)...

[04:56:02.0000] <annevk>
thanks*

[04:57:00.0000] <maikmerten>
so it may be a bit problematic to have such a deep stack of layers when it comes to security

[05:02:00.0000] <virtuelv>
annevk: mind setting properties on html files in subversion?

[05:03:00.0000] <virtuelv>
that way, you could view http://xml5.googlecode.com/svn/trunk/specification/Overview.html in a regular browser

[05:03:01.0000] <zcorpan>
so xml5 parsers don't need to implement doctypes... they can abort instead :)

[05:04:00.0000] <annevk>
yeah, quite the opposite from HTML5 :)

[05:04:01.0000] <zcorpan>
heh

[05:05:00.0000] <zcorpan>
comments work exactly the same?

[05:06:00.0000] <annevk>
with less parse errors

[05:06:01.0000] <annevk>
atm

[05:07:00.0000] <zcorpan>
for the <!-- ---> case?

[05:07:01.0000] <zcorpan>
also <!-- -- -->

[05:08:00.0000] <zcorpan>
perhaps they shouldn't be parse errors in html5

[05:09:00.0000] <zcorpan>
<!------------------> looks good ;)

[05:16:00.0000] <zcorpan>
annevk: <!DOCTYPE >> is a doctype token with the name ">", correct?

[05:16:01.0000] <annevk>
<!-- opens a comment and --> closes it

[05:16:02.0000] <annevk>
what's in between doesn't matter as long as it's not -->

[05:17:00.0000] <zcorpan>
right

[05:17:01.0000] <annevk>
zcorpan, that might be a bug

[05:17:02.0000] <zcorpan>
DOCTYPE root name before state

[05:20:00.0000] <annevk>
It seems that's handled correctly by the parser...

[05:20:01.0000] <annevk>
as in, > does not give the name

[05:21:00.0000] <zcorpan>
ok

[05:21:01.0000] <annevk>
(though the specification suggests otherwise, indeed)

[05:22:00.0000] <annevk>
guess it makes sense to end if > is spotted

[05:22:01.0000] <zcorpan>
yeah

[05:22:02.0000] <zcorpan>
not sure about <!DOCTYPE a ">">

[05:23:00.0000] <annevk>
I think the spec is correct there now...

[05:23:01.0000] <annevk>
as in, the > is part of the non-reported identifier

[05:25:00.0000] <zcorpan>
wait, what about PUBLIC and SYSTEM?

[05:26:00.0000] <zcorpan>
are they fed through the root name states?

[05:26:01.0000] <annevk>
they're safely skipped over iirc

[05:27:00.0000] <annevk>
that's the goal anyway

[05:27:01.0000] <zcorpan>
ah

[05:27:02.0000] <zcorpan>
right

[05:28:00.0000] <annevk>
during the DOCTYPE state only a few tokens are created that only affect the rest of the tokenization stage

[05:28:01.0000] <annevk>
not the parsing stage

[05:29:00.0000] <zcorpan>
DOCTYPE identifier double quoted state, EOF, shouldn't it reprocess?

[05:32:00.0000] <annevk>
yeah

[05:32:01.0000] <annevk>
there are some minor glitches like that here and there still

[05:32:02.0000] <annevk>
I've also yet to write out entities and attlist

[05:35:00.0000] <maikmerten>
annevk, oh, one thing I told Chris Double and which I tried to tell howcome (by email, but no response): I recommend not using one of the released Theora alphas for in-browser usage. It makes sense to use Theora SVN trunk, as this features a completely rewritten decoder that is felt to be much safer when it comes to malformed content. There's a compatibility layer, so you don't need to worry about yet another API.

[05:38:00.0000] <annevk>
thanks

[05:38:01.0000] <maikmerten>
however, if you adapt to a slightly revised API (theoradec.h instead of theora.h) you have access to e.g. a system of postprocessing filters, which increases the perceived picture quality

[05:38:02.0000] <maikmerten>
http://img454.imageshack.us/my.php?image=bildschirmfoto1fx6.png <-- no postprocessing, default, old decoder will look like this

[05:39:00.0000] <maikmerten>
http://img454.imageshack.us/my.php?image=bildschirmfoto2xp3.png <- new decoder, with maximum postprocessing (notice how the blocky artifacts are nicely smoothed out)

[05:39:01.0000] <maikmerten>
meh, and yet again I spam this channel with irrelevant stuff, sorry :(

[05:40:00.0000] <annevk>
it's not that irrelevant I think

[05:41:00.0000] <maikmerten>
well, but it's far away from actual WHATWG specification work

[05:41:01.0000] <zcorpan>
so? :)

[05:43:00.0000] <maikmerten>
my point is that I assume most people here aren't thaaaat interested in codec discussion or how a particular codec exposes what functions over what API, so I should keep that topic fairly low-profile

[05:50:00.0000] <hsivonen>
it is hard to get notify the tokenizer about the byte stream crossing the 512 byte mark while supporting UTF-8 sequences landing across the boundary and maintaining otherwise efficient buffering

[05:54:00.0000] <hsivonen>
s/get //

[05:56:00.0000] <annevk>
why do it through the tokenizer?

[05:58:00.0000] <hsivonen>
to check for the requirement that the internal encoding declaration has to occur within the first 512 bytes if it does occur

[05:59:00.0000] <hsivonen>
annevk: this isn't about detecting the encoding but about detecting misplaced charset metas

[06:00:00.0000] <zcorpan>
what about <style>/*<meta charset=utf-8>*/</style>? it will be detected but isn't an element in the parsed tree

[06:01:00.0000] <annevk>
oh right

[06:01:01.0000] <hsivonen>
zcorpan: as far as I can tell, having <style>/*<meta charset=utf-8>*/</style> after the first 512 bytes is not an error and my implementation plan doesn't cover detecting it

[06:02:00.0000] <annevk>
the algorithm doesn't deal with <style>, <script>, <plaintext>, etc?

[06:02:01.0000] <annevk>
interesting

[06:03:00.0000] <hsivonen>
annevk: the byte-level sniffer doesn't

[06:03:01.0000] <zcorpan>
hsivonen: ok

[06:03:02.0000] <hsivonen>
annevk: as Hixie why not :-)

[06:03:03.0000] <zcorpan>
because that's what current browsers are doing

[06:03:04.0000] <hsivonen>
zcorpan: really? I thought current browsers run the full parser twice

[06:04:00.0000] <zcorpan>
yeah, really

[06:04:01.0000] <hsivonen>
wow

[06:04:02.0000] <hsivonen>
very interesting

[06:04:03.0000] <zcorpan>
indeed :)

[06:05:00.0000] <annevk>
so current browsers are not reusing the tokenizer?

[06:06:00.0000] <annevk>
or are using the tokenizer but not using the contentmodelflag...

[06:06:01.0000] <annevk>
whoa

[06:06:02.0000] <zcorpan>
something like that

[06:06:03.0000] <zcorpan>
they detect meta charset in <style>

[06:06:04.0000] <hsivonen>
annevk: anyway, as far as I can tell, http://www.whatwg.org/specs/web-apps/current-work/#charset makes a statement about document conformance requirements about the byte placement of an attribute (where the attributeness is determined on the character stream-reading tokenizer level)

[06:06:05.0000] <hsivonen>
joy

[06:07:00.0000] <hsivonen>
I'd like to know now if I am misunderstanding requirements for conformance checkers on this point

[06:09:00.0000] <annevk>
when I last read that it's indeed as you say

[06:11:00.0000] <hsivonen>
so as far as I can tell, I have to make sure that both byte buffering and UTF-16 code unit buffering have a forced buffer boundary at that point so that a notification can happen between buffers

[06:12:00.0000] <annevk>
it only matters for ASCII compatible encodings though

[06:13:00.0000] <hsivonen>
that doesn't help much considering that UTF-8 is variable-length and various Asian encodings, too

[06:18:00.0000] <annevk>
can't you just sniff for <meta in the first 512 bytes and combine those results with the result from the tree construction?

[06:18:01.0000] <hsivonen>
annevk: what if there is no meta in the first 512 bytes but there is one afterwards?

[06:19:00.0000] <hsivonen>
annevk: I should emit an error, shouldn't I?

[06:19:01.0000] <annevk>
yeah

[06:19:02.0000] <annevk>
it wouldn't be detected

[06:19:03.0000] <annevk>
(well, for <meta charset> that is)

[06:21:00.0000] <hsivonen>
also, using the java.nio.charset stuff with reported errors *and* recovery requires a lot of work that doesn't come from the libraries by default

[06:21:01.0000] <annevk>
maybe you should focus on something else first?

[06:22:00.0000] <annevk>
/me notes that it charset detection might change...

[06:22:01.0000] <zcorpan>
the 512 requirement might be dropped altogether, aiui

[06:22:02.0000] <annevk>
as opposed to the other bits, which should be more stable

[06:22:03.0000] <zcorpan>
if browser vendors find that they have to examine the entire document anyway

[06:23:00.0000] <annevk>
zcorpan, if the entire document is several megabytes though that doesn't seem useful

[06:23:01.0000] <zcorpan>
right

[06:25:00.0000] <zcorpan>
annevk: is namespace association dealt with after the tree construction?

[06:25:01.0000] <hsivonen>
annevk: perhaps. but usually when abstraction layers are violated, it is good to cover the violation points first, because if you design with clean abstractions, it is harder to punch the holes later

[06:26:00.0000] <kfish>
maikmerten, I'd suggest another advantage of using liboggplay (apart from being cross-platform, having good sync and being simple to program against) is that it supports Ogg Skeleton, which allows streaming from time offsets, seeking by time/chapter over HTTP etc.

[06:26:01.0000] <maikmerten>
oooh, right, I totally forgot that

[06:27:00.0000] <hsivonen>
annevk: besides, reporting and recovering from malformed byte sequences is more work anyway and is likely to stay

[06:28:00.0000] <kfish>
how can i tell (from a web app) if the user agent supports html5?

[06:29:00.0000] <annevk>
you can't

[06:29:01.0000] <zcorpan>
kfish: for what purpose?

[06:29:02.0000] <annevk>
"supporting html5" is kind of broad too

[06:29:03.0000] <hsivonen>
kfish: you should check for the features you need

[06:29:04.0000] <kfish>
sure ... i want to offer an html5 page, with <video>, if the browser supports that

[06:29:05.0000] <zcorpan>
then just place the fallback inside the <video> element

[06:30:00.0000] <annevk>
var v = document.createElement("video"); if (v.play) { // prolly some support }

[06:30:01.0000] <annevk>
zcorpan, "create an element" should do the namespace stuff

[06:30:02.0000] <zcorpan>
annevk: ok

[06:30:03.0000] <annevk>
zcorpan, with a similar algorithm that's already in the XML spec

[06:30:04.0000] <annevk>
zcorpan, I've yet to implement it though

[06:31:00.0000] <kfish>
zcorpan, thanks

[06:31:01.0000] <kfish>
annevk, thanks

[06:32:00.0000] <annevk>
basically just going up the open elements array and going through the attributes for xmlns: and xmlns= magic

[06:35:00.0000] <zcorpan>
http://simon.html5.org/sandbox/html/simply-complex

[06:43:00.0000] <annevk>
hmm

[06:44:00.0000] <annevk>
/me doesn't really understand that table to begin with

[06:45:00.0000] <zcorpan>
Gez' table is the same as my two tables placed on top of each other

[06:46:00.0000] <annevk>
I don't understand his

[06:46:01.0000] <annevk>
I would love to see these on some real site

[06:46:02.0000] <annevk>
Wikipedia for instance

[06:51:00.0000] <zcorpan>
i have the periodic table with headers on 3 sides in print

[06:52:00.0000] <annevk>
so with headers on three sides, is <td> connected with all of them?

[06:52:01.0000] <zcorpan>
period on the left side (1..7), group on the top (1..18), and shells on the right (K..Q)

[06:52:02.0000] <annevk>
/me thinks the unbound algorithm should be improved

[06:53:00.0000] <zcorpan>
yeah. that is not how gez' table works though

[06:53:01.0000] <annevk>
I know

[06:53:02.0000] <annevk>
I know how his table works, I'm not sure I understand the use case

[06:53:03.0000] <hsivonen>
perhaps a table is too complex if sighted users need AT to grok it

[06:53:04.0000] <annevk>
/me ponders about creating some javascript that hilites headers

[06:54:00.0000] <annevk>
especially if you need to press ctrl+atl+5...

[06:58:00.0000] <zcorpan>
i also note that in my periodic system, the headers have headers

[06:59:00.0000] <zcorpan>
much like http://www.webelements.com/ ("Group" and "Period")

[07:02:00.0000] <zcorpan>
to make it read ok with the current system in html5, you'd have to write "Period 1", "Period 2" etc in each header cell

[07:03:00.0000] <zcorpan>
which would make the table less foreseeable for sighted users

[07:05:00.0000] <annevk>
does HTML5 forbid headers to have headers?

[07:05:01.0000] <zcorpan>
no, but the algorithm don't associate them together

[07:06:00.0000] <zcorpan>
only td->th

[07:06:01.0000] <annevk>
that should be fixable

[07:07:00.0000] <zcorpan>
in my printed table, one cell is split up to form two header cells

[07:07:01.0000] <hsivonen>
the algorithm should probably (conceptually) walk the table from the center outwards and associate outer ths as headers for inner ths

[07:12:00.0000] <hsivonen>
calculating line and col numbers for malformed byte sequences is also a fun case of violating abstraction layers

[07:16:00.0000] <zcorpan>
http://www.radiochemistry.org/periodictable/periodic_table.jpg

[07:18:00.0000] <zcorpan>
how do you mark up that?

[07:22:00.0000] <zcorpan>
would each cell contain a DL that lists all the properties of the element?

[07:23:00.0000] <Philip`>
Would you actually want to mark it up, rather than stepping back and working out what data you want to present to the user, and how you could better present it without relying on complex visual associations and patterns?

[07:23:01.0000] <zcorpan>
dunno

[07:24:00.0000] <zcorpan>
it might perhaps be more like a graph, so if you wanted it in that form, you'd use SVG

[07:25:00.0000] <Philip`>
If someone wanted to find information about a specific element, I would expect it'd be much easier if they could type in the name and get the data back

[07:25:01.0000] <Philip`>
(i.e. using an input box on a form, rather than a table)

[07:27:00.0000] <zcorpan>
yeah

[07:29:00.0000] <zcorpan>
or use a table, where each cell just contains the symbol (and/or full name) that is a link to a page that lists the properties of that element

[07:36:00.0000] <zcorpan>
annevk: it seems like whitespace outside the root element is a parse error in xml5

[07:43:00.0000] <annevk>
hmm

[07:49:00.0000] <annevk>
doing some simple table iterating isn't that hard it seems

[07:50:00.0000] <annevk>
just start at a cell and go in some direction :)

[08:11:00.0000] <annevk>
http://www.andybudd.com/archives/2007/06/rebooted/ "although I still maintain that re-introducing the font tag is a VERY BAD IDEA, and sends out all the wrong signals"

[08:12:00.0000] <annevk>
/me was on stage defending the font tag :)

[08:12:01.0000] <annevk>
never thought I'd do that a couple of years back

[08:16:00.0000] <gsnedders>
I still have my doubts about it

[08:16:01.0000] <annevk>
oh, me too

[08:16:02.0000] <annevk>
although I don't really see a viable alternative

[08:16:03.0000] <annevk>
<span style=font-family:verdana> is worse

[08:16:04.0000] <gsnedders>
what were the reasons for not using <span>?

[08:17:00.0000] <annevk>
what are the reasons for using span?

[08:17:01.0000] <gsnedders>
some editors (like iWeb) already use it, we get screamed at less, etc.

[08:17:02.0000] <annevk>
and some don't

[08:18:00.0000] <annevk>
using <span style> over <font> for political reasons seems bad

[08:18:01.0000] <gsnedders>
agreed

[08:19:00.0000] <annevk>
<font> also seems easier to parse than <span style=> given that <span style=> has way more use cases

[08:19:01.0000] <krijnh>
They both seem bad

[08:19:02.0000] <annevk>
well yeah, but there's no semantic editor that's actually used so far

[08:20:00.0000] <krijnh>
Mine is :]

[10:15:00.0000] <zcorpan>
an <img> that is display:none won't request the image, right?

[10:17:00.0000] <annevk>
I believe <img> is always fetched

[10:17:01.0000] <zcorpan>
really?

[10:17:02.0000] <annevk>
(for instance, var i = new Image(); i.src = "blah")

[10:17:03.0000] <zcorpan>
oh sure, but that's a different case from <img> in the markup, no?

[10:18:00.0000] <annevk>
it's the same <img>

[10:18:01.0000] <zcorpan>
hrm

[10:18:02.0000] <annevk>
though I suppose Opera may have not loaded display:none <img> at some point...

[10:20:00.0000] <zcorpan>
data:text/html,<img style=display:none src=javascript:alert('foo')>

[10:20:01.0000] <zcorpan>
doesn't alert in opera (but removing display:none does)

[10:23:00.0000] <zcorpan>
what is a simple way to test it in other browsers?

[10:24:00.0000] <annevk>
src=img onload=fires?

[10:24:01.0000] <hsivonen>
has anyone tested what happens when C1 range Unicode characters are document.written?

[10:25:00.0000] <hsivonen>
do they stay intact or are they turned into the Unicode characters that occupy the C1 byte range in Windows-1252?

[10:26:00.0000] <zcorpan>
data:text/html,<img style=display:none src=data:, onerror=alert('foo')>

[10:26:01.0000] <zcorpan>
hm, so firefox does load

[10:27:00.0000] <zcorpan>
so does ie7

[10:29:00.0000] <annevk>
it's funny how the table examples given use <td><b>...

[10:59:00.0000] <zcorpan>
i've figured something out

[10:59:01.0000] <zcorpan>
if there is one thing about web design that is future proof, it's quirks mode

[11:11:00.0000] <hsivonen>
zcorpan: XHTML!

[11:11:01.0000] <zcorpan>
ha

[11:11:02.0000] <zcorpan>
that's just a middle-step to XML+XSLT anyway, isn't it ;)

[11:12:00.0000] <zcorpan>
(XSLT converting it back to HTML)

[11:18:00.0000] <hsivonen>
annevk: FWIW, Python doesn't come with a UTF-32 codec by default, either

[11:18:01.0000] <hsivonen>
hard to generate test data :-)

[11:23:00.0000] <othermaciej>
UTF-32 is so simple to transcode to UTF-16 or UTF-8, I'm surprised any reasonably complete text system would be missing the codec

[11:24:00.0000] <hsivonen>
othermaciej: well, both Sun's/Apple's JDK and Python are missing it

[11:25:00.0000] <hsivonen>
ICU4J has an optional jar that adds support to Java 1.4 or later

[11:59:00.0000] <zcorpan>
forums.whatwg.org won't load for me

[12:07:00.0000] <Philip`>
/me wonders if it's possible in JS to evaluate a string in a clean scope, so it can't access the variables that are visible to the evaluator, except for a set of explicitly shared variables, like with Python's eval(string, globals, locals)

[15:17:00.0000] <Hixie>
annevk: yt?

[15:18:00.0000] <Hixie>
annevk: http://bugs.webkit.org/show_bug.cgi?id=8872 might be relevant for you


2007-06-05
[17:01:00.0000] <Lachy>
I've just been asked to write an article for A List Apart, but I'm not sure what to write about

[17:01:01.0000] <zcorpan>
can you write about anything you want?

[17:01:02.0000] <Lachy>
yeah

[17:03:00.0000] <Dashiva>
Did they indicate what kind of article they wanted?

[17:03:01.0000] <zcorpan>
write about the google gears <-> html5 conspiracy

[17:03:02.0000] <Lachy>
lol

[17:03:03.0000] <Hixie>
hah

[17:04:00.0000] <zcorpan>
:)

[17:04:01.0000] <Lachy>
what's the conspiracy?

[17:04:02.0000] <zcorpan>
dunno

[17:04:03.0000] <zcorpan>
your call

[17:04:04.0000] <Dashiva>
It's not in html4, so it must be evil and proprietary

[17:05:00.0000] <zcorpan>
if there's an ala article about it, then it has to be some conspiracy ;)

[17:05:01.0000] <Lachy>
I'll have to learn something about google gears then

[17:06:00.0000] <Dashiva>
Maybe you could work in the privacy scare about google street view

[17:07:00.0000] <Lachy>
:-D

[17:07:01.0000] <Lachy>
oh, and apparently I have to organise a 3 minute presentation for Web Jam this thursday

[17:07:02.0000] <Lachy>
I'm considering presenting the video element

[17:07:03.0000] <jruderman>
streets aren't private!? i better put some clothes on next time i walk to work.

[17:08:00.0000] <Lachy>
jruderman: just keep an eye out for an unmarked vehicle with cameras on the roof.  Otherwise, you can continue walking to work naked

[17:09:00.0000] <Dashiva>
And make your cats knows how to draw the curtians

[17:09:01.0000] <zcorpan>
Lachy: did you see håkons presentation on the <video> element?

[17:09:02.0000] <Lachy>
no

[17:09:03.0000] <zcorpan>
http://video.google.com/videoplay?docid=5545573096553082541&q=the+video+element

[17:09:04.0000] <Lachy>
oh, yeah, I think I did

[17:10:00.0000] <Lachy>
where can I find a build of Opera with support for <video>?

[17:11:00.0000] <Dashiva>
labs.opera.com I think

[17:13:00.0000] <Lachy>
thanks

[17:13:01.0000] <zcorpan>
entries in labs.opera.com don't have URIs?

[17:15:00.0000] <Lachy>
ok, now I need to find an example video (or make one). Any suggestions?  Maybe I could take one from wikipedia

[17:16:00.0000] <zcorpan>
http://people.opera.com/howcome/2007/video/three.html

[17:16:01.0000] <Lachy>
thanks

[17:16:02.0000] <zcorpan>
/me notes that that page contains a <DOCTYPE> tag

[17:17:00.0000] <Lachy>
lol

[17:38:00.0000] <Lachy>
nice! http://www.bluishcoder.co.nz/2007/05/support-for-html-video-element-in.html

[17:48:00.0000] <zcorpan>
/me wonders why most links that are posted in here are purple

[17:58:00.0000] <Lachy>
does anyone know if there is any documentation available for which <video> features Opera supports in that build?

[17:58:01.0000] <Hixie>
.play(), .stop(), and .pause(), i think

[17:58:02.0000] <zcorpan>
see their proposal sent to the list

[17:59:00.0000] <Lachy>
ok

[17:59:01.0000] <Lachy>
I'm considering making a video of myself lip syncing to some song for the presentaiton. Any suggestions for a song?

[18:01:00.0000] <zcorpan>
http://video.google.com/videoplay?docid=-6739710473912337648&q=lip+syncing

[18:02:00.0000] <Lachy>
I had one suggestion for a paris hilton song ;-)

[18:06:00.0000] <zcorpan>
which one?

[18:19:00.0000] <Lachy>
he wasn't specific about which one

[18:35:00.0000] <Lachy>
hmm, it's not working with the video I created.  I converted a .mov to .ogg using ffmpeg2theora and it won't play in Opera

[18:36:00.0000] <zcorpan>
have you tried any other ogg file?

[18:36:01.0000] <Lachy>
yes, the ogg I downloaded from those Opera demos works fine

[18:37:00.0000] <zcorpan>
then i don't know

[18:45:00.0000] <Hixie>
hmmm

[18:46:00.0000] <Hixie>
/me considers the "Attribute for holding private data for scripting" thread

[18:47:00.0000] <othermaciej>
role!

[18:48:00.0000] <othermaciej>
(j/k)

[18:48:01.0000] <Hixie>
actually i was thinking of dumping this into my "role" folder for later consideration, but it seems this actually has some use cases

[18:49:00.0000] <Hixie>
though the thread itself is free of any such information

[18:49:01.0000] <Lachy>
what are the use cases?

[18:49:02.0000] <Hixie>
that's my question too

[18:49:03.0000] <othermaciej>
I can give you some examples

[18:50:00.0000] <othermaciej>
dojo widgets in markup

[18:50:01.0000] <othermaciej>
they want to add key/value pairs to the markup for use by script code later

[18:50:02.0000] <othermaciej>
class only lets you give flat values, not key-value pairs

[18:50:03.0000] <Hixie>
do you have a sample uri showing this?

[18:50:04.0000] <othermaciej>
right now they just use nonstandard attributes

[18:50:05.0000] <othermaciej>
let me find you some example

[18:50:06.0000] <othermaciej>
s

[18:51:00.0000] <Hixie>
/me was also told today that dojo was supporting role="", but has yet to see an example of that either

[18:51:01.0000] <othermaciej>
I have no idea what that would even mean

[18:52:00.0000] <othermaciej>
http://dojotoolkit.org/demos/email

[18:52:01.0000] <othermaciej>
look at the subframe source

[18:52:02.0000] <othermaciej>
a brief sample from the source:

[18:52:03.0000] <othermaciej>
  <div id="treePane" dojoType="TreeV3" toggle="wipe" toggleDuration="500" listeners="treePaneController;treePaneIcons;treePaneSelector" sizeMin="20" sizeShare="15">

[18:52:04.0000] <othermaciej>
   <div dojoType="TreeNodeV3" title="Mail Account" nodeDocType="FolderMailbox">

[18:52:05.0000] <othermaciej>
    <div dojoType="TreeNodeV3" title="Inbox" nodeDocType="FolderInbox"></div>

[18:53:00.0000] <othermaciej>
besides dojo, one assumes XBL widgets will want to be able to support some extended attribute-like key-value mechanism in the markup, without forcing the document to be nonconforming

[18:53:01.0000] <Hixie>
wow, that page is an accessibility disaster

[18:54:00.0000] <Hixie>
/me looks

[18:54:01.0000] <othermaciej>
that's probably why they'd like to do some role-type thing

[18:54:02.0000] <Hixie>
there's a hell of a lot they could do before getting there

[18:55:00.0000] <Hixie>
like using actual list elements for their lists

[18:55:01.0000] <Lachy>
I am having no luck at all.  If I encode the video using ffmepg2theora, the video won't play in Opera.  If I encode it using VLC, it will play but there's no sound :-(

[18:55:02.0000] <othermaciej>
it's kind of div soup

[18:56:00.0000] <Hixie>
just disable styles to see what i mean

[18:56:01.0000] <Hixie>
there's no reason a page should depend on css that much

[18:56:02.0000] <Hixie>
to be usable

[18:56:03.0000] <othermaciej>
at least they use real checkboxes and buttons

[18:57:00.0000] <othermaciej>
anyway, point being, this is an example of a possible use case - I can't vouch for quality of their toolkit or even validity of this example

[18:57:01.0000] <othermaciej>
but it seems reasonable to me that for late-bound script or for XBL2 you will want something that acts like extra attributes

[18:57:02.0000] <othermaciej>
and it would be nice if you could do that without making your document nonconforming

[18:58:00.0000] <Hixie>
yeah, i agree that there are use cases

[18:58:01.0000] <Hixie>
i'm studying them to see if i can find good examples and work out what the spec should say

[19:02:00.0000] <Hixie>
man, that demo page is a testament to irrelevant=""

[19:04:00.0000] <Hixie>
i'm not really seeing any good examples of custom attributes here though

[19:04:01.0000] <Hixie>
most of them are presentational

[19:04:02.0000] <Hixie>
the rest could be folded into class=""

[19:05:00.0000] <Hixie>
these pages are why i want to ban <div>

[19:05:01.0000] <Hixie>
god

[19:12:00.0000] <webben_>
Hixie: I think the place to look for functioning role examples would be the Mozilla access pages.

[19:13:00.0000] <webben_>
especially http://developer.mozilla.org/en/docs/Accessible_DHTML#Sample_widgets

[19:13:01.0000] <webben_>
(if you want to UA support, best get yourself the accessibility toolbar from ICITA and Fire Vox)

[19:14:00.0000] <webben_>
although possibly things are already working with Window-Eyes and NVDA

[19:14:01.0000] <webben_>
not sure

[19:14:02.0000] <zcorpan>
http://forums.whatwg.org/viewtopic.php?t=63 - man, like 10 proposals in one post

[19:16:00.0000] <webben_>
okay actually that page includes a checklist of what Window-Eyes JAWS and Zoomtext support already

[19:19:00.0000] <webben_>
http://reefchat.overscore.com/ is probably the most fully developed current example

[19:22:00.0000] <webben_>
information about using role in dojo is at: http://www.dojotoolkit.org/book/dojo-book-0-4/part-8-internationalization-and-accessiblity/accessibility/creating-accessible-wi

[19:25:00.0000] <zcorpan>
wonder if it's possible to split a post in phpbb

[20:21:00.0000] <Lachy>
woo hoo! I finally got a video of me to work in Opera :-)

[23:25:00.0000] <Hixie>
woot, Folder/Directory "input-for-whatwg-dom" deleted.

[23:25:01.0000] <Hixie>
any requests for what I should work on next?

[23:46:00.0000] <hsivonen>
Hixie: from my selfish point of view, it would be nice if you looked at the corner cases of character decoding and encoding sniffing

[23:47:00.0000] <hsivonen>
Hixie: also, it would be really nice to have the spec deviations of html5lib that anne was talking about addressed in the spec

[23:49:00.0000] <Hixie>
so parsing, then

[23:49:01.0000] <Hixie>
ok, i can do the parser next

[23:49:02.0000] <weinig>
Hixie: have you investigated the behavior of passing dom functions and attribute ecmascript/js null and ecmascript/js undefined?

[23:49:03.0000] <Hixie>
there's only 400 outstanding comments related to the parser

[23:50:00.0000] <Hixie>
weinig: i'm kinda waiting to see what comes of heycam's DOM/JS spec

[23:50:01.0000] <Hixie>
weinig: i'm hoping i don't have to define any of this stuff

[23:50:02.0000] <weinig>
/me nods

[23:50:03.0000] <weinig>
thanks

[23:51:00.0000] <Hixie>
all the e-mails i've received on the topic (to whatwg) are all waiting in input-for-whatwg-dom-js-integration

[23:52:00.0000] <weinig>
Hixie: nice

[23:53:00.0000] <Hixie>
so if heycam doesn't define it, i still have the list

[23:53:01.0000] <Hixie>
but i hope i don't have to do it

[23:53:02.0000] <Hixie>
:-)

[23:56:00.0000] <hsivonen>
Hixie: thanks Re: "< Hixie> ok, i can do the parser next"

[00:54:00.0000] <hsivonen>
/me really should have IE7 available for testing... :-(

[02:08:00.0000] <annevk>
woohoo

[02:08:01.0000] <annevk>
parsing :)

[02:15:00.0000] <MikeSmith>
hsivonen - get a macbook and run parallels with Linux and XP guest OSes:)

[02:23:00.0000] <hsivonen>
MikeSmith: my PowerMac is too new and fast to justify the expense of a new Mac.

[03:01:00.0000] <annevk>
hsivonen, hey, you're making our parser lib harder to implement!

[03:02:00.0000] <annevk>
/me wonders if DOCTYPE sniffing is like charset sniffing or if it's actually part of tokenization

[03:03:00.0000] <hsivonen>
annevk: it can be part of the tokenization unless you are IE.next

[04:08:00.0000] <annevk>
http://open.info.nl/archief/2007/06/05/html-5-liever-vandaag-dan-morgen/

[04:09:00.0000] <hsivonen>
Google Translator does not support Dutch :-(

[04:09:01.0000] <ddfreyne>
the annevk translator does :>

[04:10:00.0000] <hsivonen>
/me will try to read in German/English/Swedish quirks mode

[04:10:01.0000] <ddfreyne>
funny how the first "new" thing in html5 they mention is the doctype… as if that's what html5 is about

[04:12:00.0000] <ddfreyne>
ignore that

[04:12:01.0000] <Philip`>
Babel Fish makes a valiant effort at translating Dutch

[04:12:02.0000] <hsivonen>
Philip`: thanks

[04:22:00.0000] <MikeSmith>
cool to see that he mentions the conformance checker

[04:22:01.0000] <MikeSmith>
is "ook" a real word in Dutch?

[04:22:02.0000] <MikeSmith>
I thought that was just a caveman word

[04:22:03.0000] <ddfreyne>
heh, it's dutch for "also"

[04:23:00.0000] <MikeSmith>
ddfreyne - cool, I think I'll start using that in english too -- I like it a lot better than "also"

[04:25:00.0000] <annevk>
It's also "too"

[04:29:00.0000] <annevk>
hsivonen, yeah, they asked about it

[04:29:01.0000] <MikeSmith>
annevk - whose site is that (open.info.nl) ... I see lots of stuff in the webstandaarden category

[04:29:02.0000] <annevk>
Probably something to mention by default

[04:29:03.0000] <annevk>
MikeSmith, Dutch web company

[04:30:00.0000] <MikeSmith>
k

[04:39:00.0000] <annevk>
What actually happens for <script></script><base>?

[04:39:01.0000] <annevk>
does the script get refetched?

[04:40:00.0000] <annevk>
or <script> document.write(<base>) </script> :)

[05:21:00.0000] <hsivonen>
annevk: they == IE.next team?

[06:03:00.0000] <annevk>
hsivonen, oops, meant to say that to Mike

[06:47:00.0000] <mpt_>
hsivonen, you have wonderful nouns

[06:49:00.0000] <mpt_>
"walled-gardenism", "academic time sink", "charmod correctness fig leaf"

[07:04:00.0000] <hsivonen>
mpt_: :-)

[08:43:00.0000] <annevk>
/me likes "blackbox reverse engineering"

[09:11:00.0000] <zcorpan>
annevk: ie7 handles <base> the same in standards mode and quirks mode

[09:12:00.0000] <annevk>
I know

[09:12:01.0000] <annevk>
but how are the specific cases I mentioned above handled?

[09:13:00.0000] <zcorpan>
oh, this was re your mail to jonas

[09:14:00.0000] <annevk>
oh i know

[09:14:01.0000] <annevk>
oh, already said that :)

[09:16:00.0000] <zcorpan>
ah, so you meant that it would change to option 2, not option 3

[09:25:00.0000] <annevk>
/me is confused

[09:27:00.0000] <zcorpan>
you said "I suppose 1 would be the option I pick although I wonder how long it takes before that starts breaking stuff too if people code towards the new IE7."

[09:28:00.0000] <zcorpan>
so, if stuff starts to break, i.e. if there are more pages that rely on ie7's behavior instead of ie6's, then it would switch to option 2 instead of option 1

[09:29:00.0000] <zcorpan>
i initially thought you meant that it would switch to option 3

[09:34:00.0000] <annevk>
ah

[09:35:00.0000] <annevk>
besides the potential reparsing of stuff in <head> (do browsers actually do that?!)

[09:35:01.0000] <zcorpan>
dunno

[09:35:02.0000] <annevk>
there's also the issue of what to do with href= when it contains something like "www.example.org"

[09:36:00.0000] <annevk>
treat it as a directory name (Opera), domain name (IE7), or error (Firefox)

[09:36:01.0000] <zcorpan>
ie7 treats it as a domain name??

[09:36:02.0000] <zcorpan>
wow

[09:36:03.0000] <annevk>
(Firefox requires actual URIs iirc)

[09:36:04.0000] <annevk>
"complete URIs"

[09:37:00.0000] <zcorpan>
yeah

[09:37:01.0000] <zcorpan>
html4 doesn't allow relative uris

[09:37:02.0000] <annevk>
if only it defined error handling

[10:41:00.0000] <annevk>
ah, Boris tells me what the answer is

[14:28:00.0000] <zcorpan>
http://www.accessifyforum.com/viewtopic.php?t=8083&postdays=0&postorder=asc&start=0#53117

[15:09:00.0000] <gsnedders>
apparently <p></p> isn't an empty element…

[15:09:01.0000] <gsnedders>
*is

[15:10:00.0000] <zcorpan>
gsnedders: why wouldn't it be?

[15:11:00.0000] <gsnedders>
zcorpan: SGML and XML both define <p/> (I know that's invalid) as empty element syntax

[15:12:00.0000] <gsnedders>
people are arguing that you can close tags with the self closing syntax in HTML, 'cos the validator says so.

[15:21:00.0000] <zcorpan>
what it means in sgml depends on the sgml declaration

[15:22:00.0000] <zcorpan>
with the sgml decl for html4 it is valid and equivalent to <p>>, where the next / closes the P

[15:22:01.0000] <gsnedders>
zcorpan: that's my point

[15:22:02.0000] <gsnedders>
zcorpan: I'm being told it's valid, and equiv to <p></p>

[15:25:00.0000] <zcorpan>
ok

[15:25:01.0000] <gsnedders>
which is plainly untrue.

[15:28:00.0000] <othermaciej>
gsnedders: <p/> in SGML includes the > in the text content, the validator even says so

[15:29:00.0000] <gsnedders>
othermaciej: I know

[15:32:00.0000] <gsnedders>
othermaciej: wait… how do you get the content to be shown under the new version of the validator?

[15:32:01.0000] <othermaciej>
gsnedders: don't know, I only remember seeing it on the old one

[15:35:00.0000] <gsnedders>
ironically this actually came out of me complaining about people not knowing anything, yet claiming to always be right

[15:35:01.0000] <gsnedders>
I can cite as many specs as I want, but it all gets lost.


2007-06-06
[20:12:00.0000] <MikeSmith>
(asked the following over on public-html, but want to ask here also)

[20:12:01.0000] <MikeSmith>
I think it would be useful to have a somewhere a high-level "What problems we are trying to solve with HTML5" description.

[20:12:02.0000] <MikeSmith>
Suggestions?

[20:13:00.0000] <MikeSmith>
I think "interoperability among browsers" may be a big one (and interoperable error handling).

[20:14:00.0000] <MikeSmith>
maybe also, "better support for writing Web applications (instead of just Web documents)"

[20:15:00.0000] <zcorpan>
that part is interesting

[20:15:01.0000] <MikeSmith>
... "riqorously/thoroughly documenting conformant application behavior"

[20:15:02.0000] <zcorpan>
because html5 introduces new features for web apps, people think that html5 is good for web apps, but xhtml2 is better for "structured documents"

[20:16:00.0000] <MikeSmith>
zcorpan - yeah, I can see that being a inference that some would draw

[20:17:00.0000] <zcorpan>
some also think that xhtml2 is better because you can embed svg and other xml namespaces in it, and not realising that you can do the same in xhtml5

[20:18:00.0000] <othermaciej>
we could even make it possible in HTML

[20:19:00.0000] <zcorpan>
yeah

[20:25:00.0000] <MikeSmith>
I think that engaging much in that discussion might obscure that the important distinction is that HTML5 has as probably its primary goal to precisely specify behavior of conformant UAs (HTML processing applications), less so conformant authoring applications

[20:26:00.0000] <MikeSmith>
XHTML2 spec does not really have that as a goal (as far as I can see)

[20:26:01.0000] <MikeSmith>
I guess my take on the which-is-better-for-authoring thing is, it's mostly a matter of what your authoring requirements are, or a matter of taste ... anyway, not something worth battling about

[20:27:00.0000] <MikeSmith>
or to put it another way, author in whatever language you want, as long as you transform your source into conformant HTML5 before delivering it to UAs

[20:29:00.0000] <MikeSmith>
for many use cases, neither authoring directly in HTML5 nor in XHTML2 are the best choice

[20:29:01.0000] <MikeSmith>
but authoring instead on some custom vocabulary whose content models closely match your content, then transform that to what you deliver to UAs

[20:30:00.0000] <othermaciej>
HTML5 does indeed define conforming documents and therefore what conforming authoring tools must output

[20:30:01.0000] <othermaciej>
I think authoring in HTML is better than authoring in a custom vocabulary if you are going to do anything dynamic

[20:30:02.0000] <othermaciej>
because then your script code can act directly on the model rather than a transformed view

[20:33:00.0000] <karlUshi>
othermaciej: are you promoting the end of MySQL ;)

[20:34:00.0000] <MikeSmith>
othermaciej - I guess my point about that is there are a range of opinions about what's best for authoring, and it's open to debate and there's more value as far as communicating "what problems is HTML5 trying to solve" in focusing on the stuff that's not really debatable

[20:35:00.0000] <karlUshi>
agreed with MikeSmith 

[20:37:00.0000] <othermaciej>
well, HTML5 aims to make things better for UA interoperability, as a target format, and as a direct authoring format

[02:41:00.0000] <annevk>
http://edward.oconnor.cx/2007/BarCamp-San-Diego/

[02:59:00.0000] <annevk>
seems the <pre>\n "hack" needs to be implemented for <textarea> as well jeremyb

[02:59:01.0000] <annevk>
euh jgraham

[03:02:00.0000] <annevk>
the spec now deals with the entities but not yet with the incorrect bytes...

[03:35:00.0000] <annevk>
http://ln.hixie.ch/?start=1181118077&count=1

[03:36:00.0000] <othermaciej>
I've been reading that

[03:36:01.0000] <othermaciej>
lots of amusing lines

[03:40:00.0000] <annevk>
/me barely has the time for rewriting the CSSOM

[03:40:01.0000] <annevk>
there's only a few people on this planet who understand CSS well enough to write a spec for it

[03:41:00.0000] <annevk>
then there's only a few people who are good at writing specifications

[03:41:01.0000] <annevk>
the union of both is Hixie I think

[03:42:00.0000] <annevk>
/me wants <datagrid> to handle sortable tables without scripting

[03:45:00.0000] <tantek>
annevk, there's also very few who have the time to write/edit a CSS spec

[03:47:00.0000] <annevk>
yeah, it be much like the fulltime job HTML5 is

[03:48:00.0000] <othermaciej>
the combination of having the time and the ability rules out a whole lot of possible candidates

[03:49:00.0000] <annevk>
all of them so far :(

[03:49:01.0000] <othermaciej>
I guess one could also add "inclination"

[03:50:00.0000] <annevk>
same goes for some of the SVG stuff btw...

[03:51:00.0000] <tantek>
annevk, I'd rather see a CSS Shapes draft before an SVG rewrite

[03:51:01.0000] <othermaciej>
in the SVG WG, having spec-writing ability and knowledge of relevant technology does not seem to be a requirement for editorship

[03:51:02.0000] <tantek>
it seems that most use of shapes on the web are decorative, not content

[03:51:03.0000] <tantek>
thus more appropriate to be done as a "styling"

[03:51:04.0000] <tantek>
and besides, markup is for *marking up* text

[03:52:00.0000] <annevk>
you could use XBL to hide the SVG images from actual content

[03:54:00.0000] <othermaciej>
SVG does contain some but not all of the needed capabilities, but it makes them all pretty awkward to use in combination with HTML markup

[04:36:00.0000] <hsivonen>
btw, I'm finding that the tokenizer can easily be implemented as a recursive descent tokenizer without an explicit state variable

[04:37:00.0000] <hsivonen>
wrapper loops are needed for attributes and the data state to avoid arbitrarily deep recursion

[04:38:00.0000] <mikeday>
buffering?

[04:38:01.0000] <mikeday>
oh, you're doing SAX

[04:38:02.0000] <hsivonen>
mikeday: I intend to do SAX with and without buffering, DOM and XOM

[04:38:03.0000] <mikeday>
so the recursion is just for eg. see a '<', call parseStartTag() ?

[04:38:04.0000] <hsivonen>
mikeday: this is the Tokenizer only

[04:39:00.0000] <mikeday>
/me nods

[04:39:01.0000] <hsivonen>
mikeday: yes

[04:39:02.0000] <mikeday>
so if you don't use arbitrary recursion, technically you don't need to recurse at all, right?

[04:39:03.0000] <annevk>
if you introduce new states...

[04:39:04.0000] <annevk>
and allow it to start in arbitrary states

[04:39:05.0000] <mikeday>
you could just jump around inside a big single function

[04:40:00.0000] <hsivonen>
mikeday: well, to avoid stack overflow regardless of input, I have a loop around the attribute states so that the stack rewinds back to the loop between attributes

[04:41:00.0000] <mikeday>
right, eg. while getAttribute() ...

[04:41:01.0000] <hsivonen>
yes

[04:41:02.0000] <mikeday>
but you don't actually need recursive calls, if you're not parsing a recursive grammar

[04:41:03.0000] <mikeday>
it's just for convenience structuring your code, yes?

[04:41:04.0000] <hsivonen>
this is for code structuring, yes

[04:42:00.0000] <hsivonen>
also, I am assuming that a straight final method invocation in Java is going to be faster than state lookup plus method dispatch

[04:42:01.0000] <mikeday>
hmm, Java has no goto, right? :)

[04:43:00.0000] <hsivonen>
mikeday: no goto in .java level

[04:43:01.0000] <mikeday>
right

[04:43:02.0000] <mikeday>
sounds pretty good then :)

[04:43:03.0000] <hsivonen>
mikeday: my reasoning is that this is as good as it gets without goto and jump arithmetic based on input token

[04:43:04.0000] <othermaciej>
the way to code a state machine is a loop with a switch statement

[04:44:00.0000] <othermaciej>
not via dynamic method dispatch

[04:44:01.0000] <mikeday>
s/the way/a way/ :)

[04:44:02.0000] <othermaciej>
the efficient way

[04:45:00.0000] <hsivonen>
othermaciej: you get as many method invocations either way, right?

[04:45:01.0000] <othermaciej>
hsivonen: well, I'm not sure why you contrasted "static final method invocation" with the other option

[04:46:00.0000] <hsivonen>
straight--not static

[04:46:01.0000] <hsivonen>
othermaciej: if you have one method per state

[04:47:00.0000] <hsivonen>
othermaciej: and state B follows A, why would I return to a dispatch loop in between?

[04:47:01.0000] <othermaciej>
depends on whether function calls are more expensive in your language than conditional branches

[04:48:00.0000] <hsivonen>
othermaciej: ah, you are assuming that I could do away with function calls

[04:48:01.0000] <hsivonen>
othermaciej: I am assuming one method per state either way for code structuring sanity

[04:48:02.0000] <hsivonen>
(since this is human-maintained code--not generated code)

[04:48:03.0000] <hsivonen>
I'm hoping the HotSpot does some inlining

[04:49:00.0000] <othermaciej>
well, with the switch, the compiler and/or the Java runtime can definitely inline everything into the switch statement

[04:49:01.0000] <mikeday>
I guess a parsing DSL that compiled down to Java byte code could help

[04:49:02.0000] <othermaciej>
if each processing method is final and they don't call each other

[04:49:03.0000] <hsivonen>
othermaciej: good point

[04:49:04.0000] <hsivonen>
othermaciej: thanks

[04:50:00.0000] <othermaciej>
anyway I don't know which way would be faster in Java

[04:50:01.0000] <othermaciej>
I don't have a lot of experience performance-tuning Java code

[04:50:02.0000] <othermaciej>
(though I do have performance-tuning experience in general)

[04:50:03.0000] <hsivonen>
yeah, this is guesswork without either benchmarking or knowing what HotSpot inlines

[04:51:00.0000] <hsivonen>
ok. I'll convert to a switch that is potentially inlineable

[04:52:00.0000] <mikeday>
a bit of premature optimisation going on here perhaps :)

[04:52:01.0000] <mikeday>
by the way, have you done meta charset detection yet?

[04:52:02.0000] <hsivonen>
mikeday: written--not run

[04:52:03.0000] <othermaciej>
depends on whether hsivonen finds it easier to code a finite state machine or a recursive descent parser

[04:53:00.0000] <mikeday>
hmm, I better hurry up then, I've been dragging my feet over it

[04:53:01.0000] <hsivonen>
mikeday: in C?

[04:53:02.0000] <mikeday>
yes

[04:54:00.0000] <othermaciej>
mikeday: you're writing an HTML5 parser in C?

[04:54:01.0000] <mikeday>
yes, that's why I come here, to make me feel guilty enough to work on it some more

[04:54:02.0000] <hsivonen>
hmm. come to think of it, I still think the way I have coded this is potentially a bit more efficient if HotSpot does deep inlines

[04:55:00.0000] <hsivonen>
perhaps I leave the optimization for later after all

[04:56:00.0000] <annevk>
a collegue did some testing on tokenization in C/C++ versus Python and JavaScript

[04:56:01.0000] <annevk>
C: ~1ms, Python: ~100ms, JavaScript: ~500ms

[04:56:02.0000] <mikeday>
lucky no one is writing a parser in JavaScript I guess

[04:56:03.0000] <mikeday>
...or ARE they

[04:57:00.0000] <hsivonen>
annevk: I would expect buffering to matter a lot in that case (and string object creation)

[04:57:01.0000] <mikeday>
I guess you could use a dictionary and avoid creating new string objects where possible

[04:57:02.0000] <mikeday>
eg. precache tag names and attribute names

[04:59:00.0000] <othermaciej>
which JavaScript implementation?

[04:59:01.0000] <hsivonen>
mikeday: how do you look at a character in Python or JS without creating a string object?

[04:59:02.0000] <othermaciej>
JavaScript suffers from the boxed/unboxed distinction for strings there I guess

[04:59:03.0000] <othermaciej>
if you actually use string methods

[05:00:00.0000] <Philip`>
HotSpot should be happy with inlining methods even when they're not final or are potentially recursive

[05:00:01.0000] <mikeday>
hsivonen, buffer file to array of int instead?

[05:01:00.0000] <hsivonen>
Philip`: these are final and to a finite recursion depth

[05:01:01.0000] <hsivonen>
mikeday: ok

[05:01:02.0000] <othermaciej>
array of int is much less efficient than a string in JS

[05:01:03.0000] <annevk>
othermaciej, string methods were used, Opera 9.2 was used for testing I think

[05:01:04.0000] <Philip`>
(e.g. http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html (from 1999) talks about inlining non-final methods, and it just remembers enough to undo the optimisation if its assumptions are ever violated)

[05:02:00.0000] <annevk>
Python is already a hundred times slower...

[05:02:01.0000] <mikeday>
how about Ruby? :)

[05:02:02.0000] <othermaciej>
it's hard to beat C

[05:02:03.0000] <annevk>
We really need a C implementation if we want to use it for surveys and such

[05:02:04.0000] <othermaciej>
except sometimes with C++

[05:02:05.0000] <mikeday>
surveys?

[05:02:06.0000] <annevk>
Well, surveys covering lots of pages...

[05:02:07.0000] <othermaciej>
if I were doing it I would use C++

[05:02:08.0000] <mikeday>
bleh.

[05:03:00.0000] <annevk>
mikeday, like the research Ian did

[05:03:01.0000] <Philip`>
Even with a thousand pages, the Python one is unpleasantly slow :-(

[05:03:02.0000] <mikeday>
oh, right

[05:03:03.0000] <othermaciej>
and probably at least two open source HTML5 parsers will be written in C++ sooner or later

[05:03:04.0000] <annevk>
/me wonders how hard the browser parsers are to extract

[05:03:05.0000] <hsivonen>
IIRC, HotSpot beats C for some problems

[05:03:06.0000] <hsivonen>
will be interesting to see if this is one of them :-)

[05:04:00.0000] <mikeday>
Java beats C for malloc()

[05:04:01.0000] <mikeday>
so... don't use malloc :)

[05:04:02.0000] <hsivonen>
:-)

[05:05:00.0000] <othermaciej>
annevk: our current HTML parser does the DOM building, so probably not that easily separable

[05:05:01.0000] <Philip`>
C always wins because you can implement a JVM in it :-)

[05:06:00.0000] <annevk>
othermaciej, that's what I thought, main reason why I think having a third would be good

[05:07:00.0000] <othermaciej>
having a standalone one would be nice, it it was packaged well

[05:08:00.0000] <mikeday>
indeed.

[05:09:00.0000] <mikeday>
yay, testhtml is parsing attribute names and getting "http-equiv"

[05:10:00.0000] <othermaciej>
if I were doing it for fun, I'd do C++ implementation, C API

[05:10:01.0000] <othermaciej>
but if I have hobby coding time it will probably be spent on WebKit hacking

[05:11:00.0000] <mikeday>
hmm, not getting attribute values though. That's slightly useless.

[05:12:00.0000] <hsivonen>
(fwiw, recursive call to a finite depth with loops in the right places seems to be how others have written XML parsers in Java)

[05:12:01.0000] <mikeday>
that's also how libxml2 is written I think

[08:16:00.0000] <annevk>
/me started testing <base> himself

[08:16:01.0000] <annevk>
tests here: http://tc.labs.opera.com/html/base/

[08:40:00.0000] <annevk>
seems that IE7 happily does dynamic changes

[08:40:01.0000] <annevk>
/me just added 005 and 006

[08:41:00.0000] <annevk>
I actually already figured that out while testing XMLHttpRequest but never feeded it back to the HTML5 spec I think

[08:52:00.0000] <annevk>
So open questions: support xml:base? do dynamic changes affect baseURI or also inserted <img> etc? suport xml:base in text/html? reverse engineer IE7 href= handling?

[08:52:01.0000] <annevk>
dunno, just baseURI, dunno, if it's simple...

[09:36:00.0000] <gsnedders>
ARGH!

[09:36:01.0000] <gsnedders>
people are _still_ arguing <p/> is a self-closing element, citing the validator (which is correctly parsing it as a NET)!

[09:37:00.0000] <gsnedders>
they're also saying HTML isn't SGML, despite me citing the spec.

[09:37:01.0000] <annevk>
correctly?

[09:37:02.0000] <annevk>
point them to HTML5 and tell them that that's what browsers will implement

[09:37:03.0000] <gsnedders>
well, under the spec it is parsing it as

[09:38:00.0000] <gsnedders>
annevk: the argument is in the context of what the HTML 4.01 spec says.

[09:38:01.0000] <gsnedders>
annevk: which most certainly is SGML.

[09:38:02.0000] <annevk>
HTML4 is irrelevant

[09:38:03.0000] <gsnedders>
agreed

[09:49:00.0000] <annevk>
One use case for minlength= is search systems that don't work with less than 4 characters

[09:49:01.0000] <annevk>
However, I think that's a usability problem with those search systems and not really a good use case...

[09:55:00.0000] <Philip`>
minlength= and maxlength= seem largely unrelated, since the latter stops you entering out-of-range strings but the former presumably only stops you submitting out-of-range strings (because it'd be really horrible UI if it didn't let you delete and retype the contents of the box - though I suppose I've seen people do that anyway...)

[09:55:01.0000] <annevk>
good point

[10:29:00.0000] <duryodhan>
why were the digital signatures  left out of the new  Web Forms spec?? what patent problems are you referring to?

[10:35:00.0000] <annevk>
duryodhan, care to elaborate?

[10:36:00.0000] <duryodhan>
The Web Forms doc ...

[10:37:00.0000] <duryodhan>
sez that Digital Signatures weren't addressed because of Patent concerns 

[10:37:01.0000] <duryodhan>
what are these concerns ?

[10:37:02.0000] <duryodhan>
cos GPG/PGP etc. are easily available ...

[10:37:03.0000] <annevk>
oh, I see

[10:39:00.0000] <annevk>
duryodhan, e-mail the list if you have a solution

[10:42:00.0000] <duryodhan>
I wish :D

[10:42:01.0000] <duryodhan>
I don't know the problem ...

[16:34:00.0000] <Hixie>
the internet is very quiet today

[16:59:00.0000] <Hixie>
i wonder if i can resolve the <base> problems by simply waiting a few more months for IE7 to get more market share and for the pages that break to get fixed...

[16:59:01.0000] <Dashiva>
A tempting plan

[16:59:02.0000] <kingryan>
but that only works if you don't talk about it, right?


2007-06-07
[17:00:00.0000] <othermaciej>
Hixie: is there any estimate of how many pages are actually broken, as opposed to just possibly affected?

[17:01:00.0000] <othermaciej>
(not that I care that much about this issue except that I'd like a resolution)

[17:01:01.0000] <Hixie>
othermaciej: i couldn't find any pages that were broken that weren't CJK spam or haphazard content aggregation pages.

[17:02:00.0000] <Hixie>
othermaciej: my last check looked only for pages with multiple different <base href> values with either <a> or <img> elements with relative URIs

[17:02:01.0000] <othermaciej>
ok

[17:03:00.0000] <Hixie>
i found about 0.16% pages were affcted

[17:03:01.0000] <Hixie>
which is non-trivial

[17:03:02.0000] <Hixie>
oh this included target="" <base>

[17:04:00.0000] <Hixie>
so that's the wrong number

[17:04:01.0000] <Hixie>
hold on

[17:04:02.0000] <Hixie>
oh crap i didn't count how many were affected

[17:04:03.0000] <Hixie>
duh

[17:04:04.0000] <Hixie>
oh i see that study was looking specifically for URIs, not trying to get a count

[17:05:00.0000] <Hixie>
hm, i think i never actually looked at the results of my last study, heh

[17:07:00.0000] <Hixie>
i'll have to do more work on this

[17:10:00.0000] <Hixie>
hsivonen: yt?

[17:25:00.0000] <zcorpan>
http://simon.html5.org/temp/periodic-table.png

[17:27:00.0000] <zcorpan>
er, that was a follow-up for #html-wg

[18:49:00.0000] <zcorpan>
it seems that the best way to get good research on something is to spec the opposite of what the majority of people want

[18:50:00.0000] <Hixie>
hah

[18:50:01.0000] <Hixie>
i'm really quite impressed, there has been a lot of research done for headers=""

[18:50:02.0000] <zcorpan>
yeah

[18:50:03.0000] <Hixie>
what's weird is that none of the research really seems focussed on solving the actual problem

[18:51:00.0000] <Hixie>
it's mostly about keeping an existing solution without regard to how good it is

[19:22:00.0000] <karlUshi>
you know what you have, you never know what you will get.

[21:20:00.0000] <Lachy>
hey, is the start attribute for <video> expressed in seconds?  The spec doesn't seem to be clear http://www.whatwg.org/specs/web-apps/current-work/#start2

[21:28:00.0000] <Lachy>
Hixie, yt?

[22:32:00.0000] <Hixie>
Lachy: vaguely here

[22:32:01.0000] <Hixie>
it's games night :-)

[22:32:02.0000] <Hixie>
can you send mail about the <video> second thing?

[22:32:03.0000] <Lachy>
yeah, I later

[22:32:04.0000] <Lachy>
I *will later

[22:32:05.0000] <Hixie>
cool thanks

[22:32:06.0000] <othermaciej>
what video thing?

[22:33:00.0000] <Hixie>
ambiguity in the spec

[22:33:01.0000] <Lachy>
othermaciej: it's unclear if the value for the start attribute is specified in seconds

[22:34:00.0000] <othermaciej>
ah

[22:44:00.0000] <Lachy>
/me wishes that Opera beta with support for <video> wasn't so damn buggy!

[22:45:00.0000] <othermaciej>
do they have something closer to the spec now or just their original simple prototype?

[22:45:01.0000] <Lachy>
in projection mode, the video is strangely getting split in the middle and wrapped to the next line :-/

[22:46:00.0000] <othermaciej>
hah, line breaks in video

[22:46:01.0000] <othermaciej>
that's novel :-)

[22:46:02.0000] <Lachy>
it's alright, I found a work around! :-)

[22:47:00.0000] <Lachy>
btw, if anyone wants to see the embarrassing video I'm using to demonstrate <video> tonight, see...

[22:48:00.0000] <Lachy>
http://lachy.id.au/lib/media/2007/wannabe.ogg

[22:52:00.0000] <karlUshi>
mwahahah "mostly in secret" :) very funny

[00:34:00.0000] <annevk>
it's called innovation

[00:37:00.0000] <annevk>
Lachy, lol

[00:42:00.0000] <hsivonen>
Hixie: I'm here now

[00:47:00.0000] <annevk>
you can rename your service to "HTML5 validator" per the spec :)

[00:49:00.0000] <annevk>
/me wonders if someone is implementing <command> given that it suddenly got a stable URI

[03:56:00.0000] <mikeday>
so, someone needs to rewrite CSS from scratch eh? :)

[03:56:01.0000] <annevk>
yes

[03:57:00.0000] <annevk>
do you have a couple of years with at least 40 hours of free time each week?

[03:57:01.0000] <hsivonen>
Hixie: Minefield says of whatwg.org: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

[03:57:02.0000] <mikeday>
heh

[03:58:00.0000] <hsivonen>
hmm. Firefox works. perhaps someone broke HTTP-level compression in the latest nightly

[03:58:01.0000] <annevk>
http://twitter.com/cwilso/statuses/93612242

[03:59:00.0000] <mikeday>
hmm

[03:59:01.0000] <mikeday>
where is this "real world" of which you speak?

[03:59:02.0000] <annevk>
hehe

[04:00:00.0000] <mikeday>
(a world in which specification writers walk as gods amongst men, perhaps? :)

[04:00:01.0000] <annevk>
it's called WHATWG

[04:00:02.0000] <hsivonen>
/me hopes the CSS WG transformed itself to a more WHATWG-like group in a non-hostile way

[04:01:00.0000] <mikeday>
very diplomatic.

[04:02:00.0000] <hsivonen>
I haven't been following what's going on closely enough but the CSS 2.1 spec certainly seems to have stalled. and it would be great if "CSS5" emerged from the CSS WG itself

[04:02:01.0000] <mikeday>
I thought CSS 2.1 was supposed to be "CSS5"

[04:03:00.0000] <mikeday>
in the sense of codifying existing behaviour and expectations

[04:03:01.0000] <hsivonen>
mikeday: exactly

[04:03:02.0000] <mikeday>
shame it just shrugs when it comes to table rendering of course, but that could be fixed...

[04:04:00.0000] <annevk>
they seem to be mostly working on the spec and not on testing if it's correctly implemented and changing the spec if needed

[04:04:01.0000] <annevk>
the other problem, as Hixie indicated, is that little new stuff that is needed for web apps comes out of the CSS WG, if any

[04:05:00.0000] <mikeday>
what is the solution?

[04:06:00.0000] <mikeday>
on a tangent, I've always thought that WHATWG is more fond of JavaScript than CSS

[04:07:00.0000] <annevk>
the WHATWG is focused on improving the semantic and logical side of the problem

[04:07:01.0000] <annevk>
there was hope that the CSS WG would solve the stylistic side but that hasn't happened yet

[04:08:00.0000] <mikeday>
time to revive JSS perhaps? :)

[04:08:01.0000] <annevk>
there's also need for improving the underlying platforms, such as the DOM and HTTP and maybe the URL specs

[04:08:02.0000] <annevk>
mikeday, I'm working on a new a version of the CSSOM

[04:08:03.0000] <hsivonen>
what seems alarming to me is that Hixie as a CSS WG insider says there's a problem and I had thought that the CSS WG was the best functioning WG at the W3C. (this may be an awfully naive though, but that's what I though)

[04:09:00.0000] <hsivonen>
s/though/thought/

[04:09:01.0000] <mikeday>
hard to define "best functioning" I guess

[04:10:00.0000] <hsivonen>
well, let's say the WG whose output had the most World Wide Web relevance

[04:10:01.0000] <hsivonen>
/me doesn't consider Web Services, private XML systems, Mobile Web and Semantic Web to have that much World Wide Web relevance.

[04:10:02.0000] <mikeday>
ah, not the XQuery or RDF working groups, then :)

[04:11:00.0000] <mikeday>
in that case, only HTML and CSS working groups would be relevant, yes?

[04:11:01.0000] <mikeday>
(and HTML was defunct until recently)

[04:12:00.0000] <hsivonen>
mikeday: yes. (I was thinking of the pre-new HTML WG situation)

[04:14:00.0000] <mikeday>
strange when you think of the importance of the web, that it's development is so anarchic

[04:16:00.0000] <annevk>
that's because if you want to move forward you need implementations

[04:18:00.0000] <mikeday>
and no single vendor is responsible for the web

[04:19:00.0000] <annevk>
well, MSIE is mostly responsible for how people code their pages

[04:19:01.0000] <annevk>
although that has shifted towards other browsers now

[04:25:00.0000] <mikeday>
oh well, after the coming apocalypse I guess someone can redesign the web from scratch, and get it right

[04:26:00.0000] <Dashiva>
The same people who designed the apocalypse, no doubt

[04:26:01.0000] <annevk>
once we get perfect humans, sure

[04:28:00.0000] <mikeday>
/me grins

[05:16:00.0000] <annevk>
who can edit http://wiki.whatwg.org/wiki/IRC ?

[05:21:00.0000] <Dashiva>
10:12, 6 March 2007 Hixie (Talk | contribs) protected "IRC" (This page keeps being pointlessly spammed. [edit=sysop:move=sysop])

[05:23:00.0000] <Dashiva>
So the people at http://wiki.whatwg.org/wiki/Special:Listusers?group=sysop

[05:33:00.0000] <annevk>
k

[05:33:01.0000] <annevk>
Lachy?

[06:14:00.0000] <deltab>
is semi-protection available?

[06:15:00.0000] <deltab>
or would it not help with that?

[06:30:00.0000] <Dashiva>
The edits have been by registered accounts, so not as much

[07:52:00.0000] <annevk>
<m> really is only useful for search results I think

[07:52:01.0000] <annevk>
If you start using it for other things you can no longer use it for search results...

[07:53:00.0000] <Dashiva>
Indeed

[09:00:00.0000] <Lachy>
/me has returned

[09:01:00.0000] <Lachy>
my presentation went very well!

[09:01:01.0000] <annevk>
online?

[09:01:02.0000] <annevk>
also, see above about IRC

[09:02:00.0000] <Lachy>
I won first prize: Adobe CS3 Suite!

[09:03:00.0000] <annevk>
/me wonders where Lachy went

[09:03:01.0000] <Lachy>
I will upload the slides shortly

[09:03:02.0000] <annevk>
oh, because of the video you made?

[09:03:03.0000] <Lachy>
yes

[09:03:04.0000] <annevk>
that was very funny

[09:03:05.0000] <Lachy>
it was Web Jam 3

[09:03:06.0000] <Lachy>
yeah, it got huge laughs

[09:03:07.0000] <annevk>
lots of people?

[09:03:08.0000] <Lachy>
and I did a live performance at the end by popular demand

[09:04:00.0000] <Lachy>
that was videod too :-)

[09:06:00.0000] <Lachy>
I think there were around 70-80 people there

[09:08:00.0000] <Lachy>
annevk: what did you want me to add to that IRC page?  Did you just want me to update the link to the logs?

[09:08:01.0000] <annevk>
Lachy, can you fix http://wiki.whatwg.org/wiki/IRC per Talk:IRC?

[09:08:02.0000] <annevk>
I think that's about it

[09:08:03.0000] <Lachy>
ok

[09:08:04.0000] <annevk>
maybe you guys should make me admin

[09:12:00.0000] <Lachy>
annevk: you are now a bureacrat and sysop

[09:13:00.0000] <annevk>
ooh, new features

[09:13:01.0000] <annevk>
I'll update the page myself then

[09:13:02.0000] <Lachy>
ok, I was just about to save it, so wait

[09:13:03.0000] <annevk>
np

[09:14:00.0000] <Lachy>
done

[09:17:00.0000] <annevk>
/me deletes some spam pages

[09:27:00.0000] <annevk>
nickshanks, why can't you just use media queries?

[09:28:00.0000] <annevk>
also, did you take pixel scaling into account (CSS pixel != screen pixel) and such?

[09:33:00.0000] <Lachy>
wow! I just read Hixie's rant about the CSSWG. :-)

[09:33:01.0000] <annevk>
have some spare time the coming years?

[09:33:02.0000] <Lachy>
not that much time, unfortunately

[09:34:00.0000] <zcorpan>
does css need a complete rewrite?

[09:34:01.0000] <Lachy>
there's a lot that needs to be fixed, and quirks mode needs to be defined from scratch

[09:34:02.0000] <zcorpan>
oh quirks mode indeed

[09:35:00.0000] <annevk>
zcorpan, dunno really

[09:35:01.0000] <annevk>
the current spec is quite unclear but I don't really have suggestions ready for making it much more clear

[09:36:00.0000] <zcorpan>
i was planning on defining quirks mode as merely how it is different from css21

[09:36:01.0000] <annevk>
maybe by having more exact definitions and algorithms...

[09:37:00.0000] <zcorpan>
i think it's more productive to work on a test suite for css21 and patch css21 where necessary

[09:37:01.0000] <zcorpan>
(e.g. the table model)

[09:37:02.0000] <zcorpan>
than to rewrite the whole thing

[09:37:03.0000] <Lachy>
from the CSSWG blog: "It is not possible for W3C and the members of its working groups to go search for all possibly relevant articles on the Web." - we seem to be doing quite well with that

[09:38:00.0000] <annevk>
zcorpan, probably

[09:38:01.0000] <zcorpan>
Lachy: yeah, it's not very hard to do :)

[09:38:02.0000] <annevk>
zcorpan, however, there's also need for new features such as a flexible box model etc. and how to integrate those definitions into the rest is quite unclear to me

[09:38:03.0000] <Lachy>
Hixie gets pingbacks for the spec, zcorpan and I have del.icio.us accts with whatwg tags

[09:39:00.0000] <annevk>
/me uses blogsearch.google.com and now and then technorati

[09:39:01.0000] <Lachy>
yeah

[09:39:02.0000] <krijn>
http://www.google.com/alerts is handy too :)

[09:39:03.0000] <zcorpan>
i have subscribed to a google blogsearch feed looking for relevant words

[09:39:04.0000] <Lachy>
it would be cool if we had a WHATWG acct on del.iciou.us that anyone could add to, just like anyone can post to the WHATWG twitter acct.

[09:40:00.0000] <Lachy>
and then Hixie could use the API to automatically add any article that pings the spec

[09:42:00.0000] <zcorpan>
the blogsearch has some irrelevant pages, some contain "www.example.org/foo/bar.html5", others contain "(View as HTML5)", and i've found one that has "... what? WG ..." or some such

[09:46:00.0000] <zcorpan>
http://blogsearch.google.com/blogsearch_feeds?hl=en&q=html5+OR+xhtml5+OR+%22xhtml+5%22+OR+%22whatwg%22+OR+%22what+wg%22+OR+%22web+applications+1%22+OR+%22web+apps+1%22+OR+%22web+forms+2%22&scoring=d&ie=utf-8&num=10&output=atom

[09:47:00.0000] <zcorpan>
(searching for html-5 gets too many irrelevant hits)

[09:57:00.0000] <annevk>
Paul Hoffman++

[09:57:01.0000] <annevk>
"The status of the new document is *much* less important than its correctness and usability to HTTP implementers."

[09:58:00.0000] <Lachy>
http://lachy.id.au/dev/presentation/webjam3/

[09:59:00.0000] <Lachy>
it's built for Opera Show

[09:59:01.0000] <annevk>
all cool presentations are these days :p

[10:00:00.0000] <annevk>
it also requires a certain experimental implementation...

[10:02:00.0000] <Lachy>
btw, annevk, I discovered a strange bug while experimenting with the video in opera.  It sometimes split the video in half and word-wrapped it.  I hope that's fixed in more recent internal builds

[10:02:01.0000] <annevk>
feel free to report bugs

[10:02:02.0000] <annevk>
you're encouraged to report bugs, even :)

[10:02:03.0000] <Lachy>
I'll create a test case for it and then report it

[10:03:00.0000] <annevk>
cool

[10:28:00.0000] <nickshanks>
annevk: sorry, was not paying attention here

[10:28:01.0000] <nickshanks>
the HTTP header would be mostly for use outside of CSS

[10:28:02.0000] <nickshanks>
i used a bad example of actually negotiating a CSS file using it :)

[10:29:00.0000] <annevk>
images and such are decoded such that one image pixel is one CSS pixel

[10:29:01.0000] <annevk>
which kind of negates the entire point of high DPI images...

[10:30:00.0000] <annevk>
unless of course you override the width and height and scale it down in some way...

[10:38:00.0000] <annevk>
so unless you're changing the way <img> works I'm not sure how it helps much

[10:43:00.0000] <Lachy>
whatwg.org seems to be down

[10:43:01.0000] <billmason>
wfm just now

[10:44:00.0000] <Lachy>
try it again, check you're not loading from chache

[10:44:01.0000] <Lachy>
*cache

[10:44:02.0000] <Lachy>
http://www.dnsstuff.com/tools/ping.ch?ip=http://www.whawg.org/ gets no response

[10:44:03.0000] <billmason>
cleared cache, still wfm

[10:44:04.0000] <billmason>
whawg is misspelled, so one would suppose not  :)

[10:45:00.0000] <Lachy>
oops :-)

[10:45:01.0000] <Lachy>
I'm too tired, it's nearly 03:00 here ;-)

[10:52:00.0000] <Lachy>
I met a guy from the Adobe Flash team at Web Jam tonight, and had the greatest trouble trying to explain why effectively requiring flash for interoperably embedding video, and why the MPEG, etc. software patents were a major issue

[12:12:00.0000] <Hixie>
annevk: it needed a stable uri for my blog post ;-)

[12:13:00.0000] <annevk>
ah, fair enough :)

[12:13:01.0000] <annevk>
didn't think of that!

[12:14:00.0000] <Hixie>
hsivonen: the CSSWG is the best functioning group of the W3C, with maybe the exception of WebAPI, WAF, and HTML, which are working about as well.

[12:15:00.0000] <hsivonen>
Hixie: ok 

[12:16:00.0000] <annevk>
Hixie, now you're here, what's the reason for bimorphic content models?

[12:16:01.0000] <Philip`>
/me was thinking of changing the spec-splitter to just split on <h2> and at various human-chosen <h3>s, so it wouldn't end up with tiny pages, but that'd destabilise all the page names again

[12:17:00.0000] <Hixie>
annevk: it's to allow people to put inline content inside <div>s, <li>s, etc, instead of requiring <p>s everywhere

[12:18:00.0000] <annevk>
Why isn't <div>test<p>test</p></div> allowed?

[12:19:00.0000] <annevk>
Philip`, maybe you should generate a .htaccess at the same time that generates 302 redirects for old pages

[12:19:01.0000] <annevk>
Hixie, like %Flow from HTML5

[12:19:02.0000] <annevk>
HTML4

[12:21:00.0000] <Hixie>
what would the first piece of text mean?

[12:21:01.0000] <Hixie>
if the second is a paragraph, why would the first not be?

[12:21:02.0000] <Hixie>
e.g. consider <ol> <li> <em> Hello </em> <p> World </p> </li> </ol> -- what are the semantics of that?

[12:21:03.0000] <Hixie>
I don't understand what it means for inline content to be next to block content

[12:22:00.0000] <annevk>
a div with some text followed by a paragraph

[12:22:01.0000] <annevk>
that would be some emphased text followed by a paragraph

[12:22:02.0000] <annevk>
it doesn't look very good though

[12:23:00.0000] <Hixie>
why isn't <body> Text </body> allowed?

[12:24:00.0000] <annevk>
dunno

[12:24:01.0000] <Hixie>
basically it's always been my impression that the allowing of mixed inline and block content at the same level was a bug in HTML4

[12:24:02.0000] <Hixie>
one of the things that didn't get fixed in strict

[12:24:03.0000] <Hixie>
(<body> Text </body> is allowed in HTML4 Transitional but not strict, but <div> Text <p/> </div> is allowed in both)

[12:42:00.0000] <annevk>
did someone introduce a bug in html5lib?

[12:42:01.0000] <annevk>
it barfs at me

[12:55:00.0000] <annevk>
hmm, <legend> outside <fieldset> is _badly_ parsed

[12:56:00.0000] <annevk>
I wonder if that's required or not

[12:59:00.0000] <zcorpan_>
annevk: how is it parsed?

[12:59:01.0000] <annevk>
Opera: void tag

[12:59:02.0000] <annevk>
Firefox: ignored

[12:59:03.0000] <annevk>
IE: void tag

[12:59:04.0000] <annevk>
that's for <legend>

[13:00:00.0000] <annevk>
</legend> is ignored by Opera and Firefox and IE makes it a void tag

[13:01:00.0000] <zcorpan_>
ok

[13:01:01.0000] <zcorpan_>
also in quirks mode?

[13:01:02.0000] <annevk>
let me test

[13:01:03.0000] <annevk>
Opera: yes

[13:02:00.0000] <annevk>
other browsers: yes

[13:02:01.0000] <Hixie>
yeah it's almost as bad as <caption>

[13:03:00.0000] <Hixie>
we might have issues with <figure>

[13:03:01.0000] <Hixie>
i hope not, but...

[13:03:02.0000] <zcorpan_>
in firefox i get a parent FIELDSET

[13:03:03.0000] <annevk>
<figure> works

[13:03:04.0000] <annevk>
except in IE

[13:03:05.0000] <Hixie>
i mean <figure>'s use of <legend>

[13:03:06.0000] <annevk>
/me was testing in Firefox trunk

[13:03:07.0000] <annevk>
Hixie, that doesn't

[13:04:00.0000] <zcorpan_>
but not always... for <div><legend> it is ignored

[13:06:00.0000] <annevk>
oh right

[13:06:01.0000] <annevk>
just <legend> gives you that

[13:06:02.0000] <annevk>
that's fucked up

[13:06:03.0000] <zcorpan_>
yeah

[13:07:00.0000] <annevk>
/me wonders what Safari does

[13:07:01.0000] <annevk>
anyone care to run http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Clegend%3Ex%3C/legend%3E through Safari (tot)?

[13:24:00.0000] <MikeSmith>
annevk - got it up now in tot WebKit/Safari

[13:25:00.0000] <yod>
different tree than firefox though

[13:27:00.0000] <MikeSmith>
yod, yeah

[13:27:01.0000] <annevk>
MikeSmith, what's the tree?

[13:27:02.0000] <yod>
html

[13:28:00.0000] <yod>
 body

[13:28:01.0000] <yod>
  text x

[13:28:02.0000] <yod>
  #text x, rather

[13:28:03.0000] <yod>
innerhtml has <!DOCTYPE HTML><html><body>x</body></html>

[13:29:00.0000] <annevk>
ah, so <legend> is trimmed

[13:29:01.0000] <annevk>
I guess that pretty much settles the faith of <legend>...

[13:29:02.0000] <MikeSmith>
annevk - yeah, what yod says

[13:30:00.0000] <yod>
yeh, trimmed, whereas firefox assumes there is a fieldset around it

[13:30:01.0000] <annevk>
Firefox only does that in certain weird cases...

[13:43:00.0000] <rubys>
annevk: ping?

[13:43:01.0000] <annevk>
pong

[13:44:00.0000] <rubys>
I'm seeing 10 failures in the python tests with your latest commit

[13:44:01.0000] <annevk>
hmm

[13:44:02.0000] <annevk>
I was hoping it would be error free :(

[13:44:03.0000] <annevk>
But I couldn't get the tests to run properly

[13:46:00.0000] <rubys>
http://intertwingly.net/tmp/html5lib.log

[13:47:00.0000] <annevk>
Where is the "<" from?

[13:48:00.0000] <rubys>
look at the last test in tests/tree-construction/tests3.dat

[13:48:01.0000] <annevk>
a

[13:48:02.0000] <annevk>
one sec

[13:49:00.0000] <annevk>
can you run svn update and run the tests again?

[13:49:01.0000] <annevk>
I think I'm missing some dependencies here

[13:50:00.0000] <rubys>
python tests now pass

[13:50:01.0000] <annevk>
thanks for pinging :)

[13:50:02.0000] <annevk>
guess ruby might have a failure now for those

[13:50:03.0000] <rubys>
just curious, do you have an opinion on whether other languages should be separate projects or not?

[13:51:00.0000] <annevk>
not really

[13:51:01.0000] <annevk>
I know there's a separate C and Java project going on

[13:51:02.0000] <annevk>
although I've the feeling the Java one is more actively developed

[13:52:00.0000] <rubys>
links?

[13:53:00.0000] <annevk>
Java parser is developed by hsivonen: http://hsivonen.iki.fi/validator-about/ (not sure there's source code online yet)

[13:53:01.0000] <rubys>
validator is a bit of a different beast

[13:53:02.0000] <annevk>
Michael Day was doing one in C on sf

[13:54:00.0000] <annevk>
rubys, yes, but he's writing a parser with full error recovery

[13:54:01.0000] <annevk>
http://libhtml.sourceforge.net/ is the C one

[13:54:02.0000] <annevk>
rubys, you should be able to use his Java parser separately from the conformance checker

[13:55:00.0000] <annevk>
as a library

[13:55:01.0000] <rubys>
is it just a tokenizer, or will it do things like the adoption agency algorithm?

[13:56:00.0000] <annevk>
full HTML parser

[13:56:01.0000] <annevk>
including input stream, tokenization and tree construction as I understand it

[13:58:00.0000] <annevk>
He'll be using the tests from html5lib

[14:57:00.0000] <chiptmatt>
Afternoon, gang

[15:10:00.0000] <chiptmatt>
It's always great to sit back and just take in the intellectual conversation

[15:18:00.0000] <zcorpan_>
chiptmatt: afternoon

[15:18:01.0000] <chiptmatt>
Ahh, life on the channel!

[15:34:00.0000] <chiptmatt>
so, zcorpan_, are you a regular here?

[15:44:00.0000] <zcorpan_>
chiptmatt: yeah

[15:47:00.0000] <chiptmatt>
Hixie's post about the CSS working group has me inspired. 

[15:52:00.0000] <chiptmatt>
Although I'm a little unsure about where to start helping out

[15:53:00.0000] <zcorpan_>
chiptmatt: work out exactly how browsers implement the table model

[16:06:00.0000] <chiptmatt>
No problem! I'll get right on that


2007-06-08
[18:10:00.0000] <zcorpan_>
http://wcagsamurai.org/ errata now published

[18:21:00.0000] <zcorpan_>
/me notes that <noscript> is banned

[01:08:00.0000] <annevk>
geez

[01:19:00.0000] <annevk>
(the geez was in reply to the responses to my CRLF post)

[01:19:01.0000] <annevk>
http://www.css3.info/pulling-back-the-curtain-opening-up-the-css-working-group/

[01:24:00.0000] <annevk>
awesome, the google suggest code actually works :)

[01:25:00.0000] <annevk>
/me gave a presentation at Opera yesterday and then someone went ahead and scripted a back end

[01:31:00.0000] <zcorpan>
annevk: pointer?

[02:14:00.0000] <annevk>
zcorpan, http://simon.html5.org/sandbox/html/suggest/ ;)

[02:14:01.0000] <zcorpan>
annevk: ah, thanks :)

[02:15:00.0000] <annevk>
you should probably change it slightly to include a doctype :)

[02:15:01.0000] <zcorpan>
why?

[02:15:02.0000] <annevk>
to make it validate?

[02:15:03.0000] <annevk>
guess it doesn't really matter

[02:16:00.0000] <zcorpan>
wouldn't validate even with a doctype

[02:16:01.0000] <annevk>
hmm fair enough

[02:18:00.0000] <Fuzzy76>
annevk: To avoid quirks mode. Without a doctype, browsers will think your site is coded for Netscape 4 type parsing and will differ wildly from the standard when interpreting your site.

[02:18:01.0000] <Fuzzy76>
(and differ from eachother as well)

[02:18:02.0000] <zcorpan>
parsing doesn't differ wildly

[02:18:03.0000] <krijn>
Wow, what's this quirks mode thing?

[02:19:00.0000] <Fuzzy76>
zcorpan: No, but interpreting and rendering does.

[02:19:01.0000] <Fuzzy76>
ouch

[02:19:02.0000] <annevk>
Fuzzy76, rendering is slightly different, yes

[02:19:03.0000] <annevk>
/me works for a browser vendor...

[02:19:04.0000] <Fuzzy76>
I suddenly realized what channel I'm in. :) I would presume people in _here_ knows what quirks mode is. :-$

[02:19:05.0000] <annevk>
we do

[02:19:06.0000] <krijn>
:)

[02:19:07.0000] <Fuzzy76>
/me removes his foot from his mouth ;)

[02:20:00.0000] <Fuzzy76>
I hang around in a couple of web-related channels where the general knowledge is a bit lower. :p

[02:34:00.0000] <zcorpan>
"HTML 5 can and will do whatever idea pops into anyone's head. I hope the CSS working group can be a bit more discerning!" -- http://www.w3.org/mid/46683D8C.40609⊙tc

[02:38:00.0000] <annevk>
...

[03:02:00.0000] <mpt>
/me tries not to let the <crash/> element pop into his head

[03:08:00.0000] <annevk>
it implies <body>, so you should be fine

[03:09:00.0000] <annevk>
although...

[03:27:00.0000] <hsivonen>
/me doesn't like the idea that HTML WG members have to review mobileOk to avoid random third parties implying all-encompassing W3C endorsement

[03:28:00.0000] <hsivonen>
"a simple and largely hypothetical mobile user agent" yeah, right

[05:09:00.0000] <drcode>
hi all

[05:09:01.0000] <drcode>
any one can help me with xpath?

[05:09:02.0000] <annevk>
wrong channel really

[07:59:00.0000] <annevk>
hsivonen, JavaScript \r\n becomes \n

[07:59:01.0000] <annevk>
/me wonders why XML does not normalize character references

[08:37:00.0000] <annevk>
http://dutchcelt.nl/weblog/comments/html_working_group/ :)

[08:51:00.0000] <krijn>
Yeah, he's blogging again :)

[08:52:00.0000] <krijn>
Weird his feed doesn't work anymore

[08:53:00.0000] <annevk>
I had some issues with commenting

[08:53:01.0000] <annevk>
Guess it's still in the works

[08:55:00.0000] <krijn>
Grmbl, he deleted my blog from his links ;+

[08:55:01.0000] <krijn>
So that's what you get when you give 410 responses :)

[08:56:00.0000] <krijn>
Ow, wait

[08:56:01.0000] <annevk>
it's still there...

[08:56:02.0000] <krijn>
That's the "Ow, wait" part ;)

[08:58:00.0000] <krijn>
Comment spammers kept hitting me btw, even though I sent 410 headers

[08:58:01.0000] <annevk>
spammers don't have standards

[08:59:00.0000] <krijn>
They do follow 301's and 302's though :)

[08:59:01.0000] <annevk>
I didn't say they were stupid :)

[08:59:02.0000] <krijn>
Location: http://fuck.you/

[08:59:03.0000] <annevk>
although, arguably

[09:06:00.0000] <krijn>
"If you don't want to receive this spam email me at abuse⊙ci with url of your site. Thanks."

[09:06:01.0000] <krijn>
:D

[11:03:00.0000] <Philip`>
http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/ - <video> seems to be inspiring work from quite a few people

[11:09:00.0000] <maikmerten>
oh, yes, <video> is pretty fancy

[11:09:01.0000] <maikmerten>
too bad http://metavid.ucsc.edu/wiki_dev/mv_embed/sample_page.php bombs out for me with a JavaScript error

[11:09:02.0000] <maikmerten>
/me reports

[11:10:00.0000] <maikmerten>
hmm... according to their page they should be in #metavid

[11:11:00.0000] <maikmerten>
currently I don't see any of the metavid regulars in #annodex or #theora, so I'll just wait


2007-06-09
[08:05:00.0000] <krijnh>
Ping

[12:32:00.0000] <krijnh>
Sigh


2007-06-10
[03:36:00.0000] <maikmerten>
hello

[03:41:00.0000] <maikmerten>
once again some stuff on the media elements... http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/ - this script will "enable" <video> for all browsers. If native <video> support is present the script will just keep the DOM as-is - if <video> it'll embed a Java applet to play back the media, and if Java isn't there it'll try to use <embed> and hope the client has a proper plugin

[03:41:01.0000] <maikmerten>
the problem I see: As far as I see there's no way to detect if the <video> implementation a certain format

[03:42:00.0000] <maikmerten>
I think you'll have to try to put a video on the page and see if it throws an error

[03:42:01.0000] <maikmerten>
(e.g. http://www.whatwg.org/specs/web-apps/current-work/#mediaerrdecode )

[03:44:00.0000] <maikmerten>
now... we're in year 2015, browsers are around that support various MPEG codecs, Ogg Theora, Ogg Dirac, Hyper L33t codec and whatever

[03:44:01.0000] <maikmerten>
so the script would try to embed Ogg Theora... it fails.... now it'll go for Ogg Dirac.... nope. Then it goes for MPEG... nope. Ah, Hyper L33t works, pfew, lucky us

[03:45:00.0000] <maikmerten>
that may or may not take its time

[03:45:01.0000] <maikmerten>
so I wonder if media elements should carry some sort of information to carry information about formats supported

[03:46:00.0000] <maikmerten>
trial and error may not work in the long run

[03:58:00.0000] <maikmerten>
(oh, and rereading my stuff I wrote above I can only say.... insert verbs wherever suitable... gargh)

[05:00:00.0000] <annevk>
Lachy, you mean "Hixie, please sort this out"?

[05:00:01.0000] <annevk>
(re: offline resources)

[05:01:00.0000] <annevk>
maikmerten, why not just include all the <source> elements?

[05:01:01.0000] <annevk>
/me doesn't see the need for inspecting first

[05:01:02.0000] <webben_>
maikmerten: How does your script handle fallback content for <video>?

[05:01:03.0000] <webben_>
<noembed> and alt?

[05:02:00.0000] <maikmerten>
annevk, the problem is that some content vendors only have a certain subset of formats available as fallbacks

[05:03:00.0000] <annevk>
maikmerten, just give the UA all the alternative <source> elements

[05:03:01.0000] <maikmerten>
so if vendor A only has files in format B it may be good to know if this format is supported before using <video>

[05:03:02.0000] <annevk>
why?

[05:03:03.0000] <annevk>
the UA won't fetch stuff it doesn't support

[05:03:04.0000] <annevk>
it will iterate through <source>

[05:03:05.0000] <annevk>
(unless <video> has src= specified)

[05:04:00.0000] <maikmerten>
hmm... k. So a media error is only thrown if ALL given sources fail

[05:04:01.0000] <annevk>
I think a media error is thrown only once a resource is actually fetched and it appears it isn't supported or can't be decoded

[05:05:00.0000] <maikmerten>
webben_, well, that script (it's not mine) just assumes <video> will support Ogg, there's no check to see if that has gone wrong

[05:05:01.0000] <maikmerten>
webben_, however, if <video> isn't supported at all it'll go for a Java applet to decode the video

[05:06:00.0000] <webben_>
I'm not talking about video not being supported so much as embed not being supported.

[05:06:01.0000] <webben_>
(or being disabled)

[05:08:00.0000] <maikmerten>
well, actually that script seems to use <object> for plugin fallbacks

[05:09:00.0000] <maikmerten>
oh, and <embed> as nested fallback for that

[05:09:01.0000] <maikmerten>
http://metavid.ucsc.edu/wiki_dev/mv_embed/mv_embed.js

[05:10:00.0000] <maikmerten>
annevk, well, as more crude example: The Wikipedia player first determines what options are available, then does document.write stuff to embed a viable solution. No DOM manipulation afterwards, it's basically Netscape 3 compatible stuff (blame this on me, I've provided the logic)

[05:11:00.0000] <maikmerten>
so once it determined "well, yes, there's a <video> tag with a play() method" it'll use that

[05:11:01.0000] <maikmerten>
which of course goes completely wrong if the browser doesn't happen to support that particular format

[05:12:00.0000] <annevk>
you can insert <video><source src=ogg type=someoggtype> <source src=mpg type=somempgtype> </video> ...

[05:12:01.0000] <maikmerten>
personally I'd like to know what it supports without trying... as trying would most likely also have server interaction

[05:12:02.0000] <annevk>
that would not be compatible with Opera's implementation fwiw, but the idea is that that's how <video> will work

[05:12:03.0000] <maikmerten>
yeah

[05:12:04.0000] <annevk>
of course, you can still do <video src=ogg> in which case the <source> elements will be ignored

[05:13:00.0000] <annevk>
maybe we should define it that <video src=> is the final fallback...

[05:13:01.0000] <annevk>
that would make the whole thing "backwards compatible"...

[05:13:02.0000] <maikmerten>
I have to read what the type attribute is working like

[05:14:00.0000] <maikmerten>
if I can specify <video src="blubb.ogg" type="application/ogg"> and that thing throws an error without first trying to download and play back the file if Ogg is not supported everything is perfectly fine

[05:14:01.0000] <maikmerten>
(or whatever valid value for type)

[05:15:00.0000] <annevk>
type= is not on <video>

[05:16:00.0000] <Lachy>
annevk: I didn't intend to imply for Hixie to have to sort it out himself :-), I just wanted to let others know about it and start a discussion incase someone knows more about it

[05:16:01.0000] <maikmerten>
annevk, ah, stupid me

[05:16:02.0000] <maikmerten>
annevk, no wonder I missed that ;)

[05:18:00.0000] <maikmerten>
annevk, but right, if <source src="blubb.media" type="application/someformat"> immediately makes sure the <video> element reports back an error if application/someformat isn't supported that's a rather elegant thing

[05:18:01.0000] <annevk>
Lachy, well, it has been around for several months and the Firefox guys so far have not submitted stuff...

[05:18:02.0000] <annevk>
iirc

[05:18:03.0000] <annevk>
I don't think it returns an error...

[05:19:00.0000] <annevk>
But you're able to find out if it does something with it...

[05:19:01.0000] <annevk>
/me needs to study <video> some more at some point

[05:20:00.0000] <maikmerten>
would "<video id='file.media'><source type='some/mimetype'></video>" be a valid construction to determine if some/mimetype is supported?

[05:20:01.0000] <maikmerten>
I'd hope for the media element to have MEDIA_ERR_DECODE set

[05:21:00.0000] <annevk>
I think <source> would need to have src= set as well

[05:21:01.0000] <annevk>
However, I think the right way to go around it is to simply use it

[05:22:00.0000] <annevk>
and render let the fallback content handle it if it's not supported

[05:23:00.0000] <maikmerten>
okay, thanks for clarifying these issues

[05:24:00.0000] <maikmerten>
I now see all use cases that'd make sense being covered

[06:27:00.0000] <kfish>
anyone working on open source implementations of <video>, please consider coming to http://www.annodex.org/events/foms2008/


2007-06-11
[01:34:00.0000] <hsivonen>
annevk: re: "* annevk wonders why XML does not normalize character references" As I understand it, the consequences of CR-as-NCR were not considered by the WG that defined XML but the resulting spec language was retained for compat with shipped parsers

[01:34:01.0000] <hsivonen>
annevk: at this point, it seems easiest to copy the exact quirk to HTML

[03:17:00.0000] <annevk>
hmm

[03:17:01.0000] <annevk>
it's ugly

[03:17:02.0000] <annevk>
then again, it's not that big of a deal

[03:56:00.0000] <zcorpan_>
CRs can end up in the DOM anyway with createTextNode, no?

[03:58:00.0000] <annevk>
So what I often do is using \r\n or sometimes incorrectly \n\r in JavaScript and put the result in some <pre> element

[03:58:01.0000] <annevk>
there's online a single linebreak in Firefox and IE and two in Opera if you have the \n\r sequence...

[03:59:00.0000] <annevk>
So I guess the CSS spec should say something about CR and LF one way or another if they indeed both end up in the DOM

[04:00:00.0000] <annevk>
Guess I'll have to test that at some point...

[04:30:00.0000] <annevk>
http://wiki.whatwg.org/wiki/Special:Recentchanges we're getting spammed :(

[04:36:00.0000] <MikeSmith>
annevk - maybe time to consider locking down the wiki - make an additional step where new users have to ask an existing user to add them to the authorized users group before they can edit

[04:37:00.0000] <MikeSmith>
most wikis seem to have gone that route because of scripted spamming problems

[04:39:00.0000] <zcorpan_>
or perhaps try the same thing we did to the forum

[04:41:00.0000] <zcorpan_>
namely, change the captca input to name="email" and the email input to something else (NCR-encoded too iirc)

[04:41:01.0000] <annevk>
what did we do on the forum?

[04:41:02.0000] <annevk>
that worked well?

[04:41:03.0000] <zcorpan_>
yeah

[04:45:00.0000] <annevk>
I don't think I can do that though

[05:02:00.0000] <MikeSmith>
annevk (or anybody) - can you remind me what the rationale was for making the acronym element non-conformant?

[05:03:00.0000] <zcorpan_>
authors are confused as to whether they should use abbr or acronym

[05:06:00.0000] <annevk>
making the language simpler

[05:06:01.0000] <annevk>
I suppose <acronym> will be defined to be equivalent to <abbr> for UA purposes

[05:06:02.0000] <annevk>
If we're going into that level of detail anyway...

[05:06:03.0000] <zcorpan_>
though i like opera's default styling of acronym... :)

[05:07:00.0000] <zcorpan_>
(small-caps)

[05:13:00.0000] <MikeSmith>
zcorpan_, annevk - author confusion and make-the-language-simpler issues seems like a very subjective rationale for dropping it. And I would think that'd need to be weighed against fallout from the objective problem of authors taking existing instances they have that (X)HTML4 validators say are valid, then running them through an HTML5 conformance check and being confronted with conformance errors reported for all acronym instances.

[05:14:00.0000] <zcorpan_>
don't disagree

[05:16:00.0000] <annevk>
MikeSmith, changing an element name is quite simple

[05:17:00.0000] <zcorpan_>
but there's no benefit

[05:17:01.0000] <zcorpan_>
it's like changing <i> to <em> or vice versa

[05:17:02.0000] <annevk>
those are defined differently at the moment

[05:18:00.0000] <annevk>
limiting choice makes some sense in my mind and I don't think it's entirely subjective

[05:22:00.0000] <MikeSmith>
annevk - I agree that limiting choice makes a lot of sense, but I don't want to have to explain to N different authors why an HTML5 conformance checker is telling them that their HTML4-valid documents containing acronym instances are now considered non-conformant

[05:22:01.0000] <MikeSmith>
where N = many thousands

[05:24:00.0000] <zcorpan_>
that's the easy one compared to <img><p> ;)

[05:24:01.0000] <MikeSmith>
zcorpan_ - yeah

[05:31:00.0000] <annevk>
just tell them it's a bug in HTML4

[05:31:01.0000] <annevk>
that the W3C fixed

[05:32:00.0000] <annevk>
I guess I should draft up a W3C Note with differences from HTML4

[05:32:01.0000] <annevk>
at some point

[05:32:02.0000] <annevk>
and clearly state why the differences are there

[05:43:00.0000] <MikeSmith>
annevk - I would be willing to help out with putting such a Note together were you to draft it

[05:44:00.0000] <MikeSmith>
I think that (Note outlining HTML5 vs HTML4/XHTML1) differences is something that a lot of people/companies would find really helpful.

[05:44:01.0000] <MikeSmith>
some have in fact told me as much already

[05:44:02.0000] <MikeSmith>
so I think we ought to make it a priority

[05:53:00.0000] <Lachy>
regarding <acronym>, I agree the only reason it should be considered for inclusion is to ease the migration from HTML4 to HTML5 for documents that use it (if it's really widely used), but it should be defined with identical semantics to <abbr>

[06:26:00.0000] <zcorpan_>
http://forums.whatwg.org/viewtopic.php?t=9#322 - spam?

[06:27:00.0000] <annevk>
yes

[06:28:00.0000] <zcorpan_>
ok

[06:28:01.0000] <Lachy>
http://www.robertnyman.com/2007/06/07/thoughts-on-html-5/

[06:30:00.0000] <annevk>
whoa, hsivonen reviews a spec :)

[06:30:01.0000] <Lachy>
which spec?

[06:32:00.0000] <annevk>
mobileok

[06:45:00.0000] <zcorpan_>
perhaps i should review it too

[06:47:00.0000] <gavins>
hrm, gmail marked hsivonen's review of mobileok as spam

[08:05:00.0000] <annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cpre%3Ex%0Ax%3C/pre%3E%0A%3Cpre%3Ex%3Cscript%3E%20document.write%28%22%5Cn%5Cr%22%29%20%3C/script%3Ex%3C/pre%3E%0A%3Cscript%3E%20alert%28encodeURIComponent%28document.getElementsByTagName%28%22pre%22%29%5B1%5D.childNodes%5B2%5D.textContent%29%29%20%3C/script%3E "proves" that scripts are normalized in some way too

[08:05:01.0000] <annevk>
oops

[08:05:02.0000] <annevk>
it doesn't

[08:06:00.0000] <annevk>
It does show (after some tweaking) that \r\n in the input stream becomes \n too

[08:08:00.0000] <annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cpre%3E%3Cscript%3E%20document.getElementsByTagName%28%22pre%22%29%5B0%5D.textContent%20%3D%20%22x%5Cn%5Cr%5Cr%5Crx%22%20%3C/script%3E%3C/pre%3E%0A%3Cscript%3E%20alert%28encodeURIComponent%28document.getElementsByTagName%28%22pre%22%29%5B0%5D.textContent%29%29%20%3C/script%3E is a better demo to play with

[08:10:00.0000] <annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cpre%3Ex%3Cscript%3E%20document.getElementsByTagName%28%22pre%22%29%5B0%5D.firstChild.data%20%3D%20%22x%5Cn%5Cr%5Cr%5Crx%22%20%3C/script%3E%3C/pre%3E%0D%0A%3Cscript%3E%20w%28encodeURIComponent%28document.getElementsByTagName%28%22pre%22%29%5B0%5D.firstChild.data%29%29%20%3C/script%3E is one that works in IE

[08:11:00.0000] <annevk>
Interoperability is beatiful

[08:11:01.0000] <annevk>
beautiful*

[08:12:00.0000] <annevk>
Firefox breaks at \n for white-space:pre, IE at \r and Opera for both

[08:41:00.0000] <annevk>
e-mailed WHATWG with results

[09:11:00.0000] <hsivonen>
MikeSmith: I'm back here now.

[09:15:00.0000] <MikeSmith>
hsivonen - I wanted to ask (encourage) you to put together a good command-line interface to your conformance checker if/when you have time.

[09:15:01.0000] <MikeSmith>
I've been messing around with it myself, but I know you could manage to put together something much better than I can manage.

[09:16:00.0000] <MikeSmith>
If we have that, people can start experimenting with integrating conformance-checking into IDEs and such.

[09:18:00.0000] <MikeSmith>
As in, IDEs that can parse the errors/warnings and use the line/column information to flag/highlight the places in the HTML source where the problems are.

[09:20:00.0000] <MikeSmith>
hsivonen - I need to drop off for a while

[09:20:01.0000] <MikeSmith>
back on later

[09:25:00.0000] <krijnh>
http://kilianvalkhof.com/2007/web/html5-improving-the-webwhen-its-done/

[09:26:00.0000] <krijnh>
Fans annevk! ;)

[10:25:00.0000] <zcorpan_>
what does <textarea wrap=physical> do?

[10:26:00.0000] <zcorpan_>
same as wrap=hard?

[10:31:00.0000] <zcorpan_>
doesn't seem to do anything in any browser

[10:35:00.0000] <hsivonen>
zcorpan_: seen in the wild?

[10:36:00.0000] <hsivonen>
MikeSmith: For Java-based IDEs (and other Java apps) making the conformance embeddable with a clean API makes more sense. (on my todo list)

[10:36:01.0000] <zcorpan_>
hsivonen: a guy asks on a forum why it doesn't validate and what its replacement is

[10:37:00.0000] <hsivonen>
MikeSmith: I put a command line tool on my todo list

[10:38:00.0000] <hsivonen>
MikeSmith: non-Java IDEs probably don't want to bear the JVM startup cost every time, so some kind of interprocess communication thing or a JNI montrosity is needed

[10:38:01.0000] <hsivonen>
MikeSmith: for CMSs the plan for interprocess communication is a RESTful Web service API

[10:39:00.0000] <hsivonen>
MikeSmith: I don't see any obvious reason why HTTP to localhost wouldn't work for other apps

[10:40:00.0000] <hsivonen>
afk again

[10:40:01.0000] <annevk>
/me wonders what Henrik D is talking about

[10:40:02.0000] <othermaciej>
WWDC keynote coming up

[10:40:03.0000] <othermaciej>
for those who care

[10:41:00.0000] <hsivonen>
othermaciej: is it streamed live?

[10:42:00.0000] <othermaciej>
hsivonen: there's a few places featuring liveblog commentary (engadget, gizmodo, etc)

[10:42:01.0000] <othermaciej>
dunno about streaming

[10:42:02.0000] <othermaciej>
I have to shut my laptop off now

[10:42:03.0000] <hsivonen>
othermaciej: ok

[10:42:04.0000] <othermaciej>
there will be video after the fact I think

[10:42:05.0000] <hsivonen>
/me goes jogging and will watch the video later

[10:43:00.0000] <MikeSmith>
hsivonen - HTTP to localhost would work fine, but currently the conformance checker only supports http: URLs, right? (no support for file: ... )

[10:47:00.0000] <zcorpan_>
MikeSmith: http and https

[11:38:00.0000] <hsivonen>
MikeSmith: currently the checker wants to fetch the document itself using http or https. The Web service would include the ability to POST the document to the checker

[12:42:00.0000] <zcorpan_>
http://www.apple.com/safari/download/ -- safari for windows

[12:42:01.0000] <zcorpan_>
/me realises that most here might already know

[12:57:00.0000] <zcorpan_>
/me can't get it to start on XP

[13:02:00.0000] <Philip`>
Ooh, it even does <canvas>, except it seems to be based on an old version of WebKit that has some Canvex-breaking bugs :-(

[13:03:00.0000] <Philip`>
plus the bug that means I can't run my canvas tests without it crashing

[13:04:00.0000] <zcorpan_>
Philip`: it works for you on XP?

[13:04:01.0000] <billmason>
wfm on XP, fwiw.

[13:05:00.0000] <zcorpan_>
hrm. SP2?

[13:05:01.0000] <Philip`>
I'm using Windows 2000

[13:05:02.0000] <Philip`>
(on which it works)

[13:05:03.0000] <billmason>
/me is using XP Professional SP2

[13:07:00.0000] <zcorpan_>
sigh... why doesn't it work for me

[13:09:00.0000] <zcorpan_>
perhaps it requires QT?

[13:14:00.0000] <Philip`>
Hmm, doesn't seem to have any more problems than WebKit-OSX at canvas rendering, which is nice, though it's limited to the few bits I'm testing and to my memory of what bits WebKit always breaks on

[13:24:00.0000] <Philip`>
http://canvex.lazyilluminati.com/tests/tests/results.html - nothing interestingly different (unlike WebKit-Qt which applies much more creativity to its rendering)

[13:44:00.0000] <hsivonen>
zcorpan_: I didn't see that one coming. Did Apple resurrect Yellow Box for Windows?

[13:45:00.0000] <met_>
dunno why many pages are broken in Safari 3 beta? e.g. mozilla.org (Safari 2 is ok)

[13:59:00.0000] <virtuelv_>
anyone been able to get it running under Wine (Safari 3, that is)

[14:01:00.0000] <Philip`>
No - I get up to

[14:01:01.0000] <Philip`>
  ...

[14:01:02.0000] <Philip`>
  ;fixme:shell:URL_ParseUrl failed to parse L""

[14:01:03.0000] <Philip`>
  wine: Unhandled page fault on read access to 0x00000000 at address 0x6dc6ca5d (thread 0009), starting debugger...

[14:01:04.0000] <Philip`>
which isn't very useful

[14:02:00.0000] <virtuelv_>
well, you got further than me

[14:03:00.0000] <Philip`>
(Oh, now it doesn't get far either)

[14:03:01.0000] <Philip`>
Have you got as far as / beyond having problems with the C runtime?

[14:06:00.0000] <Philip`>
(s/get far/get that far/)

[14:16:00.0000] <virtuelv_>
err:module:import_dll Library MSVCR80.dll (which is needed by L"C:\\Program Files\\Safari\\icuuc36.dll") not found

[14:18:00.0000] <Philip`>
Try http://canvex.lazyilluminati.com/misc/msvcrt.tar.bz2

[14:19:00.0000] <Philip`>
(It doesn't work if you just copy the DLLs into c:\windows\system or something, because Microsoft decided DLLs were far too easy to understand so now there's this SxS system with manifests and everything so that programs have far more ways in which to fail to run without giving decent error messages)

[14:20:00.0000] <Philip`>
(and once you've written a program and made it work, you can install VS2005 SP1 and then it all stops again and you have to recompile all your libraries)

[14:20:01.0000] <Philip`>
(or at least that's my experience...)

[14:24:00.0000] <virtuelv_>
well, now I'm up to loading runtime library incorrectly

[14:26:00.0000] <Philip`>
"An application has made an attempt to load the C runtime library incorrectly"?

[14:27:00.0000] <Philip`>
Hmm, do you have those three .dll and one .manifest file in the same directory as Safari?

[14:27:01.0000] <Philip`>
(I only get that message when the manifest is missing)

[14:31:00.0000] <virtuelv_>
wine: Unhandled page fault on read access to 0x00230000 at address 0x6b262e97 (thread 0009), starting debugger...

[14:31:01.0000] <virtuelv_>
Unhandled exception: page fault on read access to 0x00230000 in 32-bit code (0x6b262e97).

[14:31:02.0000] <virtuelv_>
I tried putting them in the windows directory firsdt

[14:32:00.0000] <Philip`>
Ah, okay

[14:32:01.0000] <Philip`>
I have no idea what to do once it starts getting access violations :-)

[14:33:00.0000] <virtuelv_>
don't know if there's much we can do

[14:39:00.0000] <Philip`>
I'm not sure if Apple will be interested in bug reports saying "it doesn't work in Wine"...

[14:42:00.0000] <met_>
Philip` it has even problem with running under localized Win XP

[15:07:00.0000] <jgraham>
Is there an list email relating to rev 880 ( Parse errors for <li> <dt> <dd> closing other elements)? I don't quite see what problem is being solved.

[15:10:00.0000] <hsivonen>
jgraham: the problem being solved is making implicit closing of elements whose end tags aren't supposed to be optional parse errors

[15:10:01.0000] <hsivonen>
jgraham: and yes, there was an email to the list about it (reply to an old email of mine)

[15:45:00.0000] <jgraham>
hsivonen: Thanks.


2007-06-12
[17:15:00.0000] <Dashiva>
"The reasoning is that POST may have side effects and we don't want the tester to harm servers."

[17:16:00.0000] <Dashiva>
Because it's impossible to make a page which has side effects on GET...

[05:40:00.0000] <krijnh>
Is missing text in Safari 3 beta for Windows a known problem already? :)

[05:43:00.0000] <Fuzzy76>
I would guess so. I noticed several (new) layout glitches the 5 minutes I tested it yesterday. Along with several crashes. :p

[05:43:01.0000] <krijnh>
I had one crash

[05:43:02.0000] <krijnh>
And missing text (looks like visibility: hidden;) on every pages I visisted

[05:44:00.0000] <krijnh>
Mostly inside headings

[05:44:01.0000] <Fuzzy76>
I saw some borders and backgrounds for missing text, it almost looked like height: 0;

[05:44:02.0000] <Fuzzy76>
one middle level of a <ul>

[06:25:00.0000] <krijnh>
Fuzzy76: yeah, pretty weird stuff

[06:26:00.0000] <Philip`>
krijnh: I've seen about three other people complain about missing text, so I assume at least somebody has reported the bug :-)

[06:29:00.0000] <Philip`>
It seems to be using an old version of WebKit that has an annoying bug with Canvex, but otherwise it seems sufficiently correct and fast at rendering, so it's quite useful for testing compatibility

[06:30:00.0000] <krijnh>
Philip`: I've seen hundreds of people complaining about IE bugs ;)

[06:31:00.0000] <krijnh>
But indeed

[06:31:01.0000] <krijnh>
The'll probably vanish

[06:32:00.0000] <Philip`>
I think it would be much more reasonable if they called it 'alpha' and didn't link to it on the front page of apple.com...

[06:33:00.0000] <krijnh>
Oh well

[06:37:00.0000] <Fuzzy76>
true

[14:43:00.0000] <zcorpan_>
hmm, with "<a href>", the href attribute is dropped in ie7 and opera

[14:43:01.0000] <zcorpan_>
/me will investigate whether this happens for more attributes

[14:47:00.0000] <met_>
annevk: if there will more attacks on one wiki page, you can protect the page, see http://en.wikipedia.org/wiki/Wikipedia:This_page_is_protected

[15:49:00.0000] <zcorpan_>
oh, ie doesn't support hasAttribute() it seems

[15:58:00.0000] <Dashiva>
IE is fairly different in attribute DOM

[15:59:00.0000] <Dashiva>
You probably want .specified, if you're trying to make something work

[16:08:00.0000] <zcorpan_>
yeah


2007-06-13
[17:27:00.0000] <zcorpan_>
<a href> <area href> <input src> <iframe src> <img src>

[17:27:01.0000] <zcorpan_>
those attributes are dropped in ie7 when using empty attribute syntax

[17:34:00.0000] <zcorpan_>
firefox doesn't drop any attributes

[17:37:00.0000] <zcorpan_>
opera drops many attributes

[17:44:00.0000] <zcorpan_>
http://simon.html5.org/test/html/parsing/empty-attribute-syntax/ (the tests take a while to run... and 001.htm doesn't work in opera)

[18:01:00.0000] <Dashiva>
You really should stagger that script :)

[18:03:00.0000] <zcorpan_>
stagger?

[18:03:01.0000] <Dashiva>
setTimeout or setInterval so it doesn't run too long at a time

[18:03:02.0000] <zcorpan_>
why?

[18:05:00.0000] <Dashiva>
It's giving me the "heavy script" dialog, that's typically a bad sign

[18:05:01.0000] <zcorpan_>
so? just press "continue"

[18:05:02.0000] <zcorpan_>
it's a test case

[18:08:00.0000] <Hixie>
note that that dialog means that your test can't be automated

[18:08:01.0000] <Dashiva>
And that it impedes the tester's ability to multitask while the test runs :)

[18:08:02.0000] <zcorpan_>
what does that mean? that the results are not reliable?

[18:09:00.0000] <othermaciej>
it's harder to put things that use dialogs into automated regression testing frameworks

[18:09:01.0000] <zcorpan_>
aha

[18:09:02.0000] <zcorpan_>
ok

[18:09:03.0000] <zcorpan_>
well i've got the results already

[18:23:00.0000] <zcorpan_>
sent results to the list, although i haven't suggested any change of the spec

[18:32:00.0000] <Dashiva>
I've refined the test a bit, getting some different results

[18:34:00.0000] <Dashiva>
Guessing we're only interested in attributes that don't drop in both cases?

[18:35:00.0000] <zcorpan_>
indeed

[18:36:00.0000] <Dashiva>
As far as I can see, opera only drops event handlers

[18:36:01.0000] <Dashiva>
Oh wait, wrong opera

[18:37:00.0000] <Dashiva>
annevk: I need you :)

[18:37:01.0000] <zcorpan_>
<a =="">

[18:39:00.0000] <zcorpan_>
interesting case

[18:39:01.0000] <zcorpan_>
opera and firefox drop the attribute

[18:40:00.0000] <zcorpan_>
in ie the attribute name is the empty string and the value is =""

[18:41:00.0000] <zcorpan_>
html5 says it should have the attribute name = and the value being the empty string

[20:22:00.0000] <zcorpan_>
http://www.google.com/search?q=site%3Axml5.googlecode.com%2Fsvn%2Ftrunk%2Fspecification%2FOverview.html -- google thinks that text/plain document is text/html (check the cached version)

[22:19:00.0000] <zcorpan_>
ok, a new XP account makes safari work...

[22:19:01.0000] <othermaciej>
zcorpan_: are you trying Safari for windows?

[22:19:02.0000] <zcorpan_>
yeah

[22:20:00.0000] <othermaciej>
zcorpan_: if you hit any bugs please report them - we're trying to flush out the top critical issues now that it is getting broader testing

[22:20:01.0000] <zcorpan_>
it seems that for a number of people it crashes on startup

[22:20:02.0000] <zcorpan_>
including me

[22:20:03.0000] <zcorpan_>
but creating a new XP account makes it work

[22:20:04.0000] <zcorpan_>
for that account

[22:21:00.0000] <othermaciej>
zcorpan_: does your user account have a non-ASCII character in the username?

[22:21:01.0000] <zcorpan_>
ah

[22:21:02.0000] <zcorpan_>
yes

[22:21:03.0000] <zcorpan_>
Ä

[22:21:04.0000] <othermaciej>
zcorpan_: I think that's one of the known issues

[22:21:05.0000] <zcorpan_>
ok

[22:21:06.0000] <othermaciej>
we're definitely all over that one

[22:21:07.0000] <othermaciej>
thanks for confirmation!

[22:21:08.0000] <zcorpan_>
np

[22:39:00.0000] <zcorpan_>
othermaciej: <h1>-<h6> elements don't get their text content rendered

[22:39:01.0000] <othermaciej>
zcorpan_: hmm...

[22:39:02.0000] <zcorpan_>
othermaciej: it's there in the dom and e.g. an <input> element gets rendered

[22:39:03.0000] <othermaciej>
zcorpan_: can you try <b>?

[22:39:04.0000] <othermaciej>
some people are seeing bugs with bold and italic not showing up

[22:39:05.0000] <zcorpan_>
tried <em>

[22:40:00.0000] <zcorpan_>
oh

[22:40:01.0000] <zcorpan_>
wait

[22:40:02.0000] <zcorpan_>
yeah, that's it

[22:41:00.0000] <othermaciej>
zcorpan_: I asked hyatt to come over here - would you mind helping him find out more details of your system configuration?

[22:41:01.0000] <othermaciej>
zcorpan_: we are trying to reproduce the problem

[22:41:02.0000] <zcorpan_>
sure

[22:41:03.0000] <othermaciej>
zcorpan_: or you could come to #webkit if you don't want to spam this channel

[22:41:04.0000] <zcorpan_>
sure

[23:05:00.0000] <annevk>
ah, more people are awake this early :)

[23:05:01.0000] <othermaciej>
hi annevk!

[23:05:02.0000] <annevk>
morning

[23:17:00.0000] <hsivonen>
morning

[23:19:00.0000] <othermaciej>
hello hsivonen 

[23:24:00.0000] <hsivonen>
MikeSmith: forgot to mention in the email that the TextEmittingErrorHandler is activated by appending &out=text to the request URI

[23:24:01.0000] <hsivonen>
MikeSmith: and that it is intentional that it gives a Bad Request HTTP error if the doc= parameter is missing

[23:41:00.0000] <MikeSmith>
hsivonen - thanks

[23:41:01.0000] <MikeSmith>
'nother question: What's your timetable like for adding XML/JSON support?

[23:46:00.0000] <MikeSmith>
and yet another: Wanted to ask what tools/mechanism you're using that allows you to get line numbers back in Schematron error messages

[23:57:00.0000] <hsivonen>
MikeSmith: no schedule for XML/JSON yet. XML is pretty much designed. JSON isn't.

[23:58:00.0000] <hsivonen>
MikeSmith: I'm using Jing with SAXON 6

[00:02:00.0000] <MikeSmith>
hsivonen - does Saxon rely on an extension function to get access to the line numbers?

[00:02:01.0000] <hsivonen>
MikeSmith: I think so, yes.

[00:02:02.0000] <hsivonen>
MikeSmith: IIRC, Jing has XSLT engine-specific code for that (for SAXON and Xalan)

[00:14:00.0000] <MikeSmith>
hsivonen - OK ... I need to read up on it more, I guess

[00:16:00.0000] <MikeSmith>
hsivonen - btw, I updated from your cvs and recompiled and have been trying &out=text with some URLs for non-conformant documents, but I just keep getting a zero-byte response

[00:16:01.0000] <hsivonen>
MikeSmith: that's because you haven't filled in the implementation, yet. ;-)

[00:17:00.0000] <hsivonen>
MikeSmith: see TextEmittingErrorHandler.java

[00:17:01.0000] <hsivonen>
MikeSmith: I just refactored to the point of making you a nice stub class

[00:17:02.0000] <MikeSmith>
ah, I see ... I've actually got to do some work ... damn

[00:21:00.0000] <MikeSmith>
OK, if/when I can manage to get it put together, I'll contribute it under the MIT license

[00:21:01.0000] <hsivonen>
MikeSmith: cool

[00:23:00.0000] <annevk>
Has someone figured out body.onload versus window.onload etc. already?

[00:23:01.0000] <annevk>
Or maybe just testcases?

[00:24:00.0000] <othermaciej>
annevk: we have test cases in the WebKit layout tests

[00:24:01.0000] <othermaciej>
we changed to mostly match how Firefox does it (which does not quite match either IE or Opera)

[00:25:00.0000] <othermaciej>
I have to go home now though

[00:25:01.0000] <othermaciej>
will be back online later

[00:31:00.0000] <zcorpan_>
annevk: iirc, in firefox, it does not fire on body and then bubble up to window... it's fired on window but magically works on body too or something

[00:31:01.0000] <annevk>
/me thought body.onload set window.onload

[00:32:00.0000] <zcorpan_>
yeah, that might be how it works

[00:36:00.0000] <annevk>
but I'd actually like to know what Internet Explorer does

[01:01:00.0000] <annevk>
zcorpan_, 9.2 has still all kinds of attribute quirks if I remember correctly

[01:02:00.0000] <annevk>
Kestrel is pretty close to HTML5 I think (minus some tokenization details)

[01:03:00.0000] <zcorpan_>
annevk: ok

[01:05:00.0000] <hsivonen>
annevk: Kestrel? Opera.next?

[01:05:01.0000] <zcorpan_>
opera 10

[01:06:00.0000] <zcorpan_>
annevk: how does it handle <a =="">?

[01:06:01.0000] <zcorpan_>
er, opera 9.5 i mean

[01:07:00.0000] <zcorpan_>
opera 10 is Peregrine

[01:13:00.0000] <annevk>
I believe the official name of the next version of Opera is Kestrel

[01:13:01.0000] <annevk>
It was announced on some semi-official blog over a month ago or so

[01:14:00.0000] <annevk>
zcorpan_, dropped

[01:16:00.0000] <annevk>
<a "="test"> does "work"

[01:17:00.0000] <annevk>
Firefox drops that

[01:20:00.0000] <zcorpan_>
annevk: ok

[01:22:00.0000] <annevk>
/me isn't sure it's ok :)

[01:22:01.0000] <zcorpan_>
ie treats <a "="test"> as equivalent to <a ?="test">

[01:48:00.0000] <annevk>
The news that Safari was released on Windows drove thousands of people to my site...

[01:48:01.0000] <annevk>
crazy

[01:48:02.0000] <othermaciej>
annevk: why your site?

[01:49:00.0000] <othermaciej>
did the announcement link to you?

[01:49:01.0000] <Fuzzy76>
I'm guessing the number would've been more than thousands if that was the case :)

[01:50:00.0000] <annevk>
othermaciej, google searches for "safari on windows"

[01:50:01.0000] <annevk>
/me has this post on Swift titled "Safari for Windows" in 2006

[01:51:00.0000] <zcorpan_>
annevankesteren.nl/2006/08/swift is the 10th result

[01:51:01.0000] <othermaciej>
heh

[02:00:00.0000] <Jero>
err, didn't Hixie meant </form> tags here instead of </font>? http://html5.org/tools/web-apps-tracker?from=883&to=884

[02:03:00.0000] <annevk>
I think so

[02:14:00.0000] <hsivonen>
/me doesn't like "mobile context"

[02:15:00.0000] <annevk>
Where's that from?

[02:16:00.0000] <annevk>
By the way, why does origin in HTML5 not talk about document.domain

[02:16:01.0000] <hsivonen>
annevk: that's part of the mobileOK and dotMOBI marketing speak

[02:17:00.0000] <annevk>
Does this mean you do like "mobileOk" and "dotMOBI"? :D

[02:17:01.0000] <hsivonen>
anecdotally, tech-savvy S60 browser users hate it when sites conclude that the client is in the "mobile context"

[02:17:02.0000] <hsivonen>
annevk: umm. no :-)

[02:17:03.0000] <annevk>
Opera Mini users too I think

[02:18:00.0000] <hsivonen>
btw, the whattf repo migrated to SVN. time to update scripts...

[02:21:00.0000] <annevk>
your own scripts?

[02:21:01.0000] <hsivonen>
yes

[02:21:02.0000] <annevk>
whattf.org needs an update anyway

[02:21:03.0000] <hsivonen>
well, fantasai's scripts too

[02:23:00.0000] <annevk>
why not make it a code.google or sf project?

[02:26:00.0000] <hsivonen>
1) it was already at cvsdude and they took care of the migration without me having to figure it out (trading money for less worries), 2) Google wouldn't tell me their terms regarding the freedom to leave without me logging in first--not cool, 3) to avoid all the cruft on sf.net

[02:29:00.0000] <annevk>
re myself: "Note: The domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs, though this is not yet defined by this specification."

[03:30:00.0000] <annevk>
zcorpan_, what bug stops the attribute test from working?

[03:30:01.0000] <annevk>
zcorpan_, also, did you report it?

[03:32:00.0000] <hsivonen>
/me starts writing Java test harnesses for the html5lib test data

[03:36:00.0000] <hendry>
hsivonen: do you have an opinion on java applets?

[03:40:00.0000] <hsivonen>
hendry: yes. I think Java applets are a failure. I have used the Web before applets were launched and so far I haven't seen an applet that 1) wouldn't be better in a standalone window (e.g. WebStart) OR 2) Wouldn't be better as JavaScript OR 3) wasn't useless

[03:41:00.0000] <jruderman>
"standalone window"?

[03:42:00.0000] <hsivonen>
jruderman: the useful applets that I've seen that didn't necessarily call for JavaScript didn't benefit from being embedded in a rectangle in HTML--on the contrary

[03:43:00.0000] <jruderman>
i don't see the connection between being used in the browser and being surrounded by other things

[03:44:00.0000] <jruderman>
java does suck as a plugin, but "it's usually surrounded by other stuff when it should be width=100% height=100%" is not one of the main reasons

[03:45:00.0000] <hendry>
hsivonen: I have some requests for java in the webc distribution. I want to say no, though I feel I need some argumentation

[03:45:01.0000] <hsivonen>
jruderman: my point is that the stuff that is useful and makes sense as Java doesn't benefit from being inside the browser process

[03:46:00.0000] <annevk>
/me wonders what makes sense as Java

[03:46:01.0000] <jruderman>
lol

[03:46:02.0000] <hsivonen>
annevk: prior to <canvas>, any complex educational interactive visualization

[03:47:00.0000] <hsivonen>
annevk: demo version of Opera Mini

[03:47:01.0000] <jruderman>
the benefit of being inside the browser process is that the user doesn't have to trust you or install stuff

[03:47:02.0000] <hsivonen>
jruderman: WebStart

[03:47:03.0000] <annevk>
hsivonen, ah, yeah, demoing Opera Mini makes some sense :)

[03:48:00.0000] <hsivonen>
the main problem is that Sun didn't come up with WebStart in 1995

[03:48:01.0000] <othermaciej>
jruderman: but then people make signed applets

[03:48:02.0000] <othermaciej>
which are a pox on all mankind

[03:48:03.0000] <jruderman>
othermaciej: true, but that's only some applets

[03:48:04.0000] <zcorpan_>
annevk: dunno. i didn't

[03:49:00.0000] <hsivonen>
hendry: why do you want to say no?

[03:49:01.0000] <hsivonen>
/me wonders if Opera for Wii does Java

[03:50:00.0000] <annevk>
zcorpan_, what did you change?

[03:50:01.0000] <zcorpan_>
attributes[...].specified -> hasAttribute(...)

[03:51:00.0000] <hendry>
hsivonen: because I hate Java ;)

[03:51:01.0000] <annevk>
per http://gonintendo.com/?p=7849 it is not supported...

[03:51:02.0000] <hendry>
hsivonen: also it had 100+ megs to the distro

[03:51:03.0000] <hendry>
(i think)

[03:52:00.0000] <hendry>
i just generally feel Java shouldn't be on the Web

[03:52:01.0000] <hendry>
but I might be wrong

[03:52:02.0000] <hsivonen>
hendry: Java probably shoudn't be on the Web but it is pretty good at powering the Web on the server side

[03:53:00.0000] <hendry>
hsivonen: i'm fine with that

[03:54:00.0000] <zcorpan_>
doesn't wiki use java to embed video?

[03:54:01.0000] <hsivonen>
oh yeah, the Java Theora impl could count as useful. but then again, I'd be OK with all non-ad videos having their own windows

[03:55:00.0000] <hsivonen>
/me likes the way Flip4Mac can dispatch embedded video to QuickTime Player

[04:32:00.0000] <annevk>
What would be a good name for a method that takes a media query and returns true for false depending on whether it's applicable?

[04:33:00.0000] <annevk>
testMedia(), matchMedia() ... ?

[04:40:00.0000] <zcorpan_>
currentMedia

[04:41:00.0000] <annevk>
That .type

[04:41:01.0000] <annevk>
That's*

[04:41:02.0000] <zcorpan_>
.type of what?

[04:43:00.0000] <annevk>
window.media.type

[04:43:01.0000] <annevk>
the other case is having something like window.media.matchMedia("screen and (min-width:300px)")

[04:56:00.0000] <zcorpan_>
annevk: the snapshot feature in opera's developer console doesn't escape attribute values. e.g. & and " are not converted to entities

[05:06:00.0000] <hsivonen>
annevk: what's the purpose of html5lib sanitizer? is it for making html embedded in feeds safe for publishing at another domain?

[05:09:00.0000] <annevk>
I'm not responsible for it

[05:09:01.0000] <annevk>
for either of the things you guys mention :)

[05:55:00.0000] <Dashiva>
annevk: around?

[06:05:00.0000] <annevk>
always

[06:18:00.0000] <annevk>
these mobile people are knowingly ruining application/xhtml+xml

[06:18:01.0000] <annevk>
ouch :(

[06:18:02.0000] <annevk>
all good reasons for XML5 I suppose...

[07:19:00.0000] <annevk>
It would be nice if people could come up with actual arguments against a feature instead of "it would make me feel better"

[07:20:00.0000] <Fuzzy76>
I thought making people feel better was the main goal of HTML5? ;)

[07:21:00.0000] <annevk>
The question is of course that if we do what he asks for if he actually feels better in the long run

[07:21:01.0000] <annevk>
I'm not so sure about that

[07:23:00.0000] <annevk>
(We also can't satisfy everyone...)

[11:08:00.0000] <zcorpan_>
anyone familiar with the google maps api?


2007-06-14
[23:29:00.0000] <hsivonen>
annevk: it would be super-useful to allow diffing using http://google-diff-match-patch.googlecode.com/ in the Tracker

[23:31:00.0000] <hsivonen>
/me tries to figure out which tokenization states Hixie changed in rev 886. hard to see in diff -u

[23:35:00.0000] <hsivonen>
rev 886 is so cute

[01:33:00.0000] <Hixie>
hsivonen: the data state

[01:36:00.0000] <hsivonen>
Hixie: so I figured using google diff patch match

[01:37:00.0000] <Hixie>
ah

[02:05:00.0000] <zcorpan_>
what will <b>x<i>y</b>z</i> parse into? is it <b>x</b><i><b>y</b>z</i> or <b>x<i>y</i></b><i>z</i>?

[02:21:00.0000] <Fuzzy76>
there is no definite answer to that, it will vary between browsers afaik

[02:22:00.0000] <citoyen>
Fuzzy76: I assume the question is related to what it will parse as following HTML5

[02:22:01.0000] <Fuzzy76>
handling of incorrect nesting is also defined?

[02:23:00.0000] <zcorpan_>
Fuzzy76: yes

[02:23:01.0000] <Fuzzy76>
I _really_ need to get through that spec some day :-$

[02:23:02.0000] <annevk>
ouch, <!-- and --> parsing in <style> blocks

[02:25:00.0000] <Fuzzy76>
Every time I say something in here I seem to lodge my foot in my mouth :p

[02:31:00.0000] <annevk>
that can be solved by reading the spec multiple times in multiple directions

[02:31:01.0000] <Fuzzy76>
heh

[02:31:02.0000] <Fuzzy76>
I'll take a note of that :)

[02:34:00.0000] <Fuzzy76>
heh. Opera print preview didn't like the specs... :p

[02:35:00.0000] <citoyen>
printing is black magic

[02:37:00.0000] <Fuzzy76>
It just took a while :)

[02:37:01.0000] <citoyen>
it's a large file

[02:37:02.0000] <Fuzzy76>
401 pages

[02:38:00.0000] <zcorpan_>
Fuzzy76: http://hsivonen.iki.fi/printing-wa10/

[02:44:00.0000] <annevk>
It's funny. You ask for comments on the document itself and people start complaining about HTML5 terminology such as XHTML5

[02:47:00.0000] <Fuzzy76>
zcorpan_: Thanks for the tip. :)

[02:49:00.0000] <annevk>
Ah, the <script><!-- <script> --> </script> makes more sense now

[02:50:00.0000] <zcorpan_>
annevk: you mean <script><!-- </script> --> </script> ?

[02:51:00.0000] <annevk>
yeah

[02:59:00.0000] <annevk>
I wasn't aware it had to do with <!-- and -->

[03:01:00.0000] <annevk>
/me thinks it's kind of neat

[03:02:00.0000] <hsivonen>
annevk: your latest email to public-html probably had a copy-paste error

[03:03:00.0000] <hsivonen>
should it say ...(obviously) also not in XHTML5.

[03:05:00.0000] <annevk>
hmm

[03:05:01.0000] <annevk>
the attributes of elements, that are in HTML4 but not in HTML5, are not in HTML5

[03:05:02.0000] <annevk>
is what I'm trying to say although I wonder how useful it is given the amount of confusion

[03:06:00.0000] <hsivonen>
isn't it an obvious tautology that stuff that isn't in foo isn't in foo?

[03:06:01.0000] <zcorpan_>
/me would suggest to drop the paragraph

[03:06:02.0000] <annevk>
ok, dropped it

[03:16:00.0000] <mpt>
hsivonen, hendry: <http://news.bbc.co.uk/2/hi/technology/3791983.stm> describes millions of people who use Java embedded in Web pages

[03:16:01.0000] <MikeSmith>
annevk - What do you think of DanC's proposed introduction for the HTML5vs4 diff doc?

[03:17:00.0000] <annevk>
I'm working on that right now

[03:18:00.0000] <annevk>
The last paragraph needs some work I think

[03:18:01.0000] <annevk>
HTML became an application of SGML starting with HTML2

[03:18:02.0000] <annevk>
and I don't think any implementation ever had a fully conforming SGML parser

[03:21:00.0000] <hsivonen>
mpt: yeah, games are a case that I'd count as not benefiting from HTML embedding (i.e. better as WebStart)

[03:22:00.0000] <hsivonen>
mpt: I'm not trying to say that applet don't exist. I was just giving hendry my opinion that applets tend to always be a worse solution than WebStart or JavaScript

[03:26:00.0000] <MikeSmith>
hmm, I see Hixie recently changed part of the intro of the parsing section to read:

[03:26:01.0000] <MikeSmith>
[[

[03:26:02.0000] <MikeSmith>
The resulting confusion — with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation — has wasted decades of productivity.

[03:26:03.0000] <MikeSmith>
]]

[03:27:00.0000] <MikeSmith>
just added the "wasted decades of productivity" part

[03:28:00.0000] <mpt>
hsivonen, I haven't used Web Start, but from screenshots I'm not sure that the target audience would understand it well

[03:29:00.0000] <annevk>
MikeSmith, I don't see that here...

[03:30:00.0000] <annevk>
I see that now though

[03:33:00.0000] <hsivonen>
mpt: WebStart does suffer from the same usability vs. security problem as MIDP

[03:34:00.0000] <hsivonen>
mpt: that is, the defaults are too secure and users are asked to authorize stuff they don't understand

[03:34:01.0000] <mpt>
MIDP?

[03:34:02.0000] <hsivonen>
mpt: Java on phones

[03:34:03.0000] <hsivonen>
mpt: the thing you use to run Opera Mini

[03:35:00.0000] <mpt>
Actually, I don't :-)

[03:35:01.0000] <mpt>
but thanks for the explanation

[03:35:02.0000] <hsivonen>
Opera Mini is the only useful use case I have so far

[03:35:03.0000] <hsivonen>
although I hear that Google Maps Mini is good, too

[03:36:00.0000] <hsivonen>
(My phone is too old for Google Maps Mini)

[03:36:01.0000] <hsivonen>
mpt: anyway, every time I start using Opera Mini, I have to clear an authorization menu, which sucks

[03:39:00.0000] <MikeSmith>
hsivonen - Opera Mini the only useful use case for MIDP?

[03:39:01.0000] <hsivonen>
judging from Wii and Maemo, having Flash support in a browser is a much higher priority than having Java applet support

[03:39:02.0000] <hsivonen>
MikeSmith: so far for me, yes

[05:05:00.0000] <annevk>
hmm, more expensive checks in the data state

[05:05:01.0000] <annevk>
there has to be a way to optimize that

[05:06:00.0000] <hsivonen>
annevk: in a couple of encoding test cases the #data marker lacks a newline after it

[05:06:01.0000] <hsivonen>
annevk: is there a good reason why?

[05:06:02.0000] <hsivonen>
annevk: in html5lib

[05:07:00.0000] <annevk>
I'm afraid I didn't make those

[05:08:00.0000] <annevk>
Ask jgraham

[05:08:01.0000] <hsivonen>
annevk: ok

[05:09:00.0000] <hsivonen>
jgraham: in html5lib/testdata/encoding/tests1.dat there are a couple #data markers without a newline before the actual data. is this intentional? should I fix my harness or should you fix the test data?

[05:09:01.0000] <virtuelv>
today's fun Firefox bug

[05:10:00.0000] <virtuelv>
when the bookmarks toolbar is too small to content, Firefox continually dispatches a resize event on the document in view

[05:14:00.0000] <hsivonen>
jgraham: basically, when I am on a marker line, I skip until and including \n

[05:14:01.0000] <hsivonen>
jgraham: which fails

[05:43:00.0000] <hsivonen>
now passing encoding test cases in tests1.dat except for the two with a weird #data marker

[05:54:00.0000] <hsivonen>
argh. the html5lib encoding tests seem to assume a multicharacter delimiter

[05:54:01.0000] <hsivonen>
\n#

[05:57:00.0000] <hsivonen>
and there a place where there are two empty lines before #data

[05:57:01.0000] <hsivonen>
is the test case format documented somewhere? It seems that I've been making simplified assumptions about the format?

[05:59:00.0000] <zcorpan_>
http://wiki.whatwg.org/wiki/Parser_tests ?

[06:03:00.0000] <hsivonen>
zcorpan_: thanks but this is about the encoding sniffing test format

[06:03:01.0000] <zcorpan_>
ok

[06:17:00.0000] <hsivonen>
/me passes tests2.dat

[07:12:00.0000] <hsivonen>
whoa! 13 JSON impls in Java to choose from

[07:18:00.0000] <hsivonen>
down to 3 candidates...

[07:25:00.0000] <annevk>
hsivonen, I suggest e-mailing implementors⊙wo with html5lib issues

[07:31:00.0000] <hsivonen>
annevk: instead of filing bugs?

[07:34:00.0000] <annevk>
guess that might work as well

[11:23:00.0000] <KevinMarks>
who do I need to persuade to not use <dt><dd> in <dialog> ? 

[12:02:00.0000] <zcorpan_>
KevinMarks: why not and what do you propose instead?

[12:07:00.0000] <KevinMarks>
because it breaks assumed containment within <dl> and overloads the meaning

[12:07:01.0000] <KevinMarks>
I propose <q> instead of <dd>

[12:08:00.0000] <KevinMarks>
for <dt> you could use <cite>

[12:09:00.0000] <KevinMarks>
I can't see how using <dt> that ambiguously can make any sense

[12:10:00.0000] <KevinMarks>
<cite> and <q> have exactly the desired semantic as far as I can see

[12:10:01.0000] <zcorpan_>
<q> is a quotation from another source. in a dialog, you're not quoting from another source, it's direct speech

[12:11:00.0000] <zcorpan_>
also, html4 suggested <dl> for dialogs

[12:11:01.0000] <zcorpan_>
so if you followed html4's suggestion it is straight forward to migrate to html5 (just change <dl> to <dialog>)

[12:13:00.0000] <zcorpan_>
finally, <dt><dd> have a good default rendering for dialogs in legacy browsers

[12:22:00.0000] <virtuelv>
/me agrees with zcorpan_ 

[12:45:00.0000] <KevinMarks>
how is a definition closer in meaning to direct speech than a quotation?

[12:45:01.0000] <KevinMarks>
seriously?

[12:45:02.0000] <zcorpan>
<dd> is not a definition

[12:46:00.0000] <zcorpan>
in html4 it was, loosely, but it is defined differently in html5 (see the spec)

[12:46:01.0000] <KevinMarks>
it was defined as a definition in html3

[12:47:00.0000] <zcorpan>
so?

[12:47:01.0000] <KevinMarks>
and 4

[12:47:02.0000] <zcorpan>
yes, i said that above

[12:51:00.0000] <KevinMarks>
it is the redefinition I am objecting to

[12:51:01.0000] <KevinMarks>
it messes up semantic parsing assumptions

[12:51:02.0000] <KevinMarks>
by all means define new elements for  speaker and direct speech

[12:52:00.0000] <KevinMarks>
but don't redefine others and destroy containment rules

[12:56:00.0000] <KevinMarks>
how is "description" closer in meaning to "direct speech" than "quote" is ?

[12:56:01.0000] <KevinMarks>
the spec even says "the discourse, or quote, part in a conversation (dialog element)."

[12:59:00.0000] <KevinMarks>
did you go away?

[13:05:00.0000] <Hixie>
how does it mess up any parsing assumptions? any parser that was looking for <dt>s or <dd>s without a <dl> is already broken anyway.

[13:08:00.0000] <zcorpan>
KevinMarks: in practice, <dl>s are used for all sorts of things. if you see a <dd> that is not inside a <dl> then it was probably used for indentation

[13:37:00.0000] <gsnedders>
"The new content models only apply to the DOM and the XML serialisations, they can't be expressed in the HTML serialisation." — expressed in what way?

[13:40:00.0000] <Hixie>
in any way

[13:40:01.0000] <gsnedders>
but what do you mean by that?

[13:41:00.0000] <KevinMarks>
so you are saying "people use this ambiguously, so lets make the spec more ambiguous" ?

[13:42:00.0000] <gsnedders>
how can they be expressed in XML but not HTML?

[13:42:01.0000] <zcorpan>
KevinMarks: rather make the spec reflect the real world more closely

[13:42:02.0000] <Hixie>
KevinMarks: it's not made ambiguous, it's made much more precise than html4 ever was.

[13:42:03.0000] <Hixie>
gsnedders: in XML you could do ...<p><ul>...</ul></p>...

[13:43:00.0000] <Hixie>
gsnedders: in HTML you can't, since <p><ul> is equivalent to <p></p><ul>

[13:43:01.0000] <gsnedders>
Hixie: ah.

[13:43:02.0000] <gsnedders>
Hixie: would it be possible to have such an example in the spec?

[13:45:00.0000] <Hixie>
i thought i had

[13:45:01.0000] <KevinMarks>
"The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content." is clearer than "The dd element represents the description, definition, or value, part of a term-description group in a description list (dl element), and the discourse, or quote, part in a conversation (dialog element)."

[13:45:02.0000] <gsnedders>
I can't find any mention of the fact that it isn't possible in HTML now, even.

[13:46:00.0000] <Hixie>
8.1.2.5. Restrictions on content models

[13:46:01.0000] <Hixie>
i could add an example

[13:46:02.0000] <Hixie>
send mail asking for one?

[13:46:03.0000] <Hixie>
KevinMarks: i disagree, but ok

[13:48:00.0000] <KevinMarks>
so <dd> now means quote, as does <q>

[13:48:01.0000] <Hixie>
no

[13:48:02.0000] <Hixie>
it doesn't mean quote

[13:48:03.0000] <gsnedders>
Hixie: hmm. the prose is clearer than I remember it being.

[13:48:04.0000] <Hixie>
a quote is something someone else said

[13:48:05.0000] <zcorpan>
"and the discourse, or quote, ..."

[13:49:00.0000] <Hixie>
in <dialog>, you might not be quoting anyone (e.g. in a screenplay)

[13:49:01.0000] <Hixie>
it CAN give a quote

[13:49:02.0000] <Hixie>
e.g. if the <dialog> is used for transcribing an IM conversation

[13:50:00.0000] <zcorpan>
yeah, ok

[13:51:00.0000] <KevinMarks>
Content inside a q element must be quoted from another source

[13:51:01.0000] <KevinMarks>
IM isn't anotehr source?

[13:51:02.0000] <zcorpan>
gsnedders: where did you quote that text from regarding content models?

[13:51:03.0000] <gsnedders>
zcorpan: from a snippet I had lying around of things to question :P

[13:52:00.0000] <gsnedders>
zcorpan: I can't remember the original source

[13:52:01.0000] <zcorpan>
ok

[13:52:02.0000] <Hixie>
KevinMarks: your question seems to imply that if you have a quote you _must_ use <q>.

[13:52:03.0000] <Hixie>
KevinMarks: which is not the case

[13:52:04.0000] <Hixie>
KevinMarks: i don't really understand what the problem is you are trying to report.

[13:53:00.0000] <KevinMarks>
I'm saying <q> is a better SHOULD than <dd>

[13:53:01.0000] <Hixie>
what for, and why? and what problem does this solve?

[13:56:00.0000] <KevinMarks>
what problem does redefining <dd> solve?

[13:57:00.0000] <Hixie>
in <dialog>, you mean?

[13:57:01.0000] <KevinMarks>
what problem does <dialog> solve?

[13:58:00.0000] <zcorpan>
people don't know what markup to use for dialogs

[13:59:00.0000] <Hixie>
<dialog> solves the problem that people have come up with dozens of creative and highly verbose ways of transcribing conversations, none of which handled screenplays and scripts, and all of which were an absolute pain to use in practice. By introducing <dialog>, we can shortcircuit the entire problem with a short syntax, which happens to already work in legacy UAs.

[13:59:01.0000] <Hixie>
/me looks at an e-mail from zcorpan asking for guidance on how innerHTML should handle namespaced nodes

[14:00:00.0000] <zcorpan>
pointer?

[14:01:00.0000] <Hixie>
3 oct 96

[14:01:01.0000] <Hixie>
er

[14:01:02.0000] <Hixie>
2006

[14:01:03.0000] <Hixie>
in it you suggest using the local names for these elements and dropping the prefixes

[14:02:00.0000] <Hixie>
it's not really clear to me that we shouldn't just raise an exception

[14:02:01.0000] <Hixie>
i mean, it's not like it's going to round-trip

[14:02:02.0000] <Hixie>
whatever we do

[14:02:03.0000] <zcorpan>
a lot of things don't round-trip innerHTML

[14:04:00.0000] <Hixie>
true

[14:04:01.0000] <KevinMarks>
so why is <dialog><cite><q> no good?

[14:05:00.0000] <Hixie>
because you're not citing or quoting anyone in many cases

[14:05:01.0000] <Hixie>
e.g. screenplays

[14:05:02.0000] <Hixie>
also, it doesn't really have a good backcompat story

[14:05:03.0000] <Hixie>
you'd end up with everything in one long line

[14:05:04.0000] <KevinMarks>
er, you're not defining anyone

[14:05:05.0000] <Hixie>
?

[14:05:06.0000] <Hixie>
what do you mean?

[14:06:00.0000] <KevinMarks>
you are expanding the meaning of definiiton and term to include  speaker and speech

[14:06:01.0000] <KevinMarks>
but you won't expand the meaning of cite to speaker and quote to speech

[14:07:00.0000] <Hixie>
we're not expanding the meaning of <dt> and <dd>. <dt> and <dd> when not in a <dl> mean absolutely nothing in HTML4.

[14:07:01.0000] <Hixie>
the <dt> and <dd> elements in <dialog> elements are entirely new, they just happen to have the same spelling as elements that are used in <dl> elements.

[14:07:02.0000] <KevinMarks>
so spell them <cite> and <q>

[14:08:00.0000] <Hixie>
<cite> and <q> have defined meanings everywhere, so we _would_ be redefining them

[14:08:01.0000] <Hixie>
we would also be doing them a disfavour, by removing the only thing they mean from them in certain cases

[14:08:02.0000] <Hixie>
and, probable most importantly, you would lose the backwards compatible renderingness

[14:09:00.0000] <Hixie>
you never answered the three questions i asked earlier: what for, and why? and what problem does this solve?

[14:10:00.0000] <Hixie>
zcorpan: do you remember what you reasoning was for dropping the prefixes?

[14:12:00.0000] <KevinMarks>
<dialog><cite>Kevin Marks</cite> <q>agreement</q></dialog>

[14:12:01.0000] <KevinMarks>
<dialog><dt>Kevin Marks<dd>dissension</dialog>

[14:12:02.0000] <KevinMarks>
legacy rendition looks OK for the former

[14:13:00.0000] <Hixie>
<dialog><cite>Kevin Marks</cite> <q>agreement</q> <cite>Ian Hickson</cite> <q>look again</q></dialog>

[14:15:00.0000] <zcorpan>
Hixie: at least two browsers do it

[14:16:00.0000] <KevinMarks>
<dialog><li><cite>Kevin Marks</cite> <q>agreement</q> <li><cite>Ian Hickson</cite> <q>look again</q></dialog>

[14:16:01.0000] <Hixie>
and now we're back to having the creative and highly verbose ways i mentioned earlier

[14:17:00.0000] <zcorpan>
Hixie: although i see now that safari does what ie does, which neutralises that point

[14:18:00.0000] <zcorpan>
Hixie: or actually tips it over to me thinking that keeping the prefixes is better (since it's harder to change ie) :)

[14:19:00.0000] <Hixie>
well this is all highly academic really

[14:19:01.0000] <Hixie>
but yeah

[14:19:02.0000] <Hixie>
so you're ok with leaving the same as is?

[14:19:03.0000] <zcorpan>
leaving what?

[14:19:04.0000] <Hixie>
the definition of innerHTML

[14:20:00.0000] <zcorpan>
right now it says what safari/ie do, right?

[14:21:00.0000] <Hixie>
i believe so

[14:23:00.0000] <Hixie>
afk for 20 minutes or so

[14:23:01.0000] <zcorpan>
ok. then yes, i'm ok with leaving it as is

[14:38:00.0000] <zcorpan>
Hixie: however, none of ie, firefox, opera or safari change the case of the characters when a node is in a different namespace.

[14:40:00.0000] <zcorpan>
the spec doesn't say to change the case, but it says "(which is all lowercase)"

[14:47:00.0000] <Hixie>
back

[14:47:01.0000] <Hixie>
zcorpan: ok, i'll fix that

[14:51:00.0000] <zcorpan>
hmm, testing "br" elements with contents, in different namespaces, has interesting results

[14:58:00.0000] <Hixie>
oh?

[14:58:01.0000] <zcorpan>
will upload tests

[15:02:00.0000] <zcorpan>
http://simon.html5.org/test/html/dom/the-document/dynamic/in-html/ -- 001 and 002

[15:04:00.0000] <Hixie>
wtf is firefox doing

[15:05:00.0000] <zcorpan>
it is printing the contents of the element first as child of the br, then omitting the end tag, then printing it again as sibling

[15:05:01.0000] <zcorpan>
for 002

[15:05:02.0000] <zcorpan>
safari and opera do the same but don't omit the end tag

[15:06:00.0000] <Hixie>
but... why?

[15:06:01.0000] <zcorpan>
no idea

[15:06:02.0000] <zcorpan>
:)

[15:07:00.0000] <Hixie>
i guess it's one of those things where the topic comes into play

[15:07:01.0000] <zcorpan>
perhaps they don't want to drop anything from the dom, and don't print out the contents of empty HTML elements, but instead print out them as siblings

[15:08:00.0000] <zcorpan>
then apply the same logic to non-HTML elements which results in the same being printed twice

[15:08:01.0000] <zcorpan>
ie seems to refuse to put contents in br elements

[15:08:02.0000] <Hixie>
well, the spec just has the contents be omitted

[15:08:03.0000] <Hixie>
which i think makes more sense anyway

[15:09:00.0000] <zcorpan>
yeah

[15:10:00.0000] <zcorpan>
it's not like anyone is using elements with the tag name "br" in another namespace, with contents, and then uses innerHTML

[15:10:01.0000] <Hixie>
indeed

[15:42:00.0000] <Hixie>
zcorpan: k, fixed that

[16:05:00.0000] <jgraham>
hsivonen: The encoding tests thing is a bug which I spotted the other day and is fixed in my local tree

[16:05:01.0000] <jgraham>
/me has a generic parser for tests in that format written which enforces a very simple format


2007-06-15
[17:13:00.0000] <zcorpan>
Hixie: isn't it possible to put e.g. U+000C characters in the DOM?

[17:19:00.0000] <Hixie>
in the text?

[17:19:01.0000] <Hixie>
i guess it is

[17:19:02.0000] <Hixie>
is that non-conforming these days?

[17:20:00.0000] <Hixie>
why do people have such problems with control characters, sheesh

[17:20:01.0000] <zcorpan>
it's a well-formedness error in xml 1.0 iirc

[17:20:02.0000] <Hixie>
i think i should start a non-profit that campaigns for equal rights for control characters

[17:20:03.0000] <zcorpan>
:)

[17:20:04.0000] <zcorpan>
that was what i referred to by "illegal characters"

[17:21:00.0000] <Hixie>
yeah

[17:21:01.0000] <Hixie>
i thought you mean in XML names

[17:21:02.0000] <Hixie>
i'll add it to the list

[17:21:03.0000] <Dashiva>
We need ASCII5

[17:21:04.0000] <Dashiva>
maybe UTF5 too

[17:21:05.0000] <zcorpan>
Unicode5

[17:21:06.0000] <zcorpan>
oh, there already is a Unicode 5.0

[17:22:00.0000] <Dashiva>
Just map all those pesky control characters to NOP

[17:22:01.0000] <Dashiva>
(And then people start using them to go past content filtering, hilarity ensues)

[17:26:00.0000] <zcorpan>
nn

[17:37:00.0000] <Hixie>
so apparently control characters are fine in xml 1.1

[17:37:01.0000] <Hixie>
that's one of the few changes

[17:37:02.0000] <Hixie>
that's why i thought it was ok :-)

[17:38:00.0000] <Hixie>
i've made the spec cover this case, anyway.

[17:43:00.0000] <KevinMarks>
so we can send BEL to lynx users? excellent

[17:44:00.0000] <Hixie>
nothing says they have to render as a bell, but yep

[17:47:00.0000] <Hixie>
hm, a request for outerHTML

[17:49:00.0000] <Hixie>
hsivonen: yt?

[17:49:01.0000] <Hixie>
or anyone, in fact. any opinions on how to define how many unconvertable bytes should be converted to FFFD?

[17:50:00.0000] <Hixie>
say you have a sequence of non-UTF-8 bytes in a UTF-8 stream

[17:50:01.0000] <Hixie>
how many FFFDs do you get?

[17:50:02.0000] <Hixie>
hm

[19:11:00.0000] <Hixie>
> [...the html5 draft] does not attempt to

[19:11:01.0000] <Hixie>
> define how user agents MUST signal whether they prefer text/html or

[19:11:02.0000] <Hixie>
> application/xhtml+xml.

[19:11:03.0000] <Hixie>
hm

[19:19:00.0000] <Hixie>
wow you can really confuse IE's tokeniser if you're not careful

[19:19:01.0000] <Hixie>
e.g. <p title=x=" b > y> hello </p>

[19:32:00.0000] <jruderman>
that's a strange use of the all-caps MUST

[19:35:00.0000] <karlUshi>
yep

[19:35:01.0000] <karlUshi>
they MUST, but we do not know what

[19:35:02.0000] <karlUshi>
it doesn't work

[19:38:00.0000] <Hixie>
html5lib people -- i mislabeled one of my checkins just now, my bad. it affects you. (r901)

[00:17:00.0000] <zcorpan>
http://simon.html5.org/temp/selectors-case.txt -- my proposal for inclusion in the Selectors spec, any comments?

[00:44:00.0000] <annevk>
why XML attribute names?

[00:45:00.0000] <annevk>
and are you sure CSS is ASCII case-insensitive?

[00:45:01.0000] <zcorpan>
becase xbl2 uses xml attribute names for the selectors namespace declarations

[00:45:02.0000] <zcorpan>
or perhaps rather, it uses xml namespace declarations

[00:46:00.0000] <zcorpan>
no, i didn't look it up...

[00:46:01.0000] <hsivonen>
Hixie: Re: rev 894: You didn't mention text nodes containing forbidden characters.

[00:47:00.0000] <hsivonen>
Oops. that was addressed in email

[00:48:00.0000] <zcorpan>
forbidden characters can appear in other places other than text nodes, right?

[00:48:01.0000] <hsivonen>
zcorpan: in XML, the forbidden characters can't appear anywhere

[00:49:00.0000] <hsivonen>
zcorpan: additionally, element and attribute names have further arbitrary restrictions

[00:49:01.0000] <zcorpan>
yeah

[00:49:02.0000] <zcorpan>
perhaps it should be more catch-all and say any node that doesn't match the relevant production

[00:49:03.0000] <hsivonen>
/me sees that rev 896 mentions illegal characters

[00:50:00.0000] <annevk>
maybe just drop the last column?

[00:52:00.0000] <zcorpan>
annevk: yeah, done

[00:53:00.0000] <annevk>
zcorpan, re: entities, I think we should just fix our implementation

[00:53:01.0000] <annevk>
the spec makes many things conforming that are not actually supported

[00:54:00.0000] <zcorpan>
i think compat with legacy implementations is good

[00:54:01.0000] <annevk>
<datagrid>

[00:54:02.0000] <zcorpan>
what about it?

[00:54:03.0000] <annevk>
I think incentives to fix legacy implementations are good

[00:55:00.0000] <zcorpan>
oh sure

[00:55:01.0000] <zcorpan>
don't not fix your implementations :)

[00:56:00.0000] <zcorpan>
even if we don't care about compat with legacy implementations, making the ; optional makes errors harder to spot and makes the code less readable

[00:56:01.0000] <annevk>
depends on the particular construct

[00:56:02.0000] <annevk>
if whitespace is following...

[00:57:00.0000] <zcorpan>
true

[01:03:00.0000] <hsivonen>
hmm. looks like the tokenization spec will have changed by the time my impl passes unit tests. :-)

[01:05:00.0000] <hsivonen>
Hixie: my implementation currently relies on the java.nio.charset.CharsetDecoder notion of bad byte sequence grouping

[01:05:01.0000] <hsivonen>
Hixie: I'll get back to you about how it groups stuff.

[01:06:00.0000] <hsivonen>
Hixie: IIRC, for UTF-8 a plausible first byte of an UTF-8 sequence starts a new run of bad bytes

[01:07:00.0000] <hsivonen>
Hixie: I'm rather unsympathetic to defining it precisely if the definition disagrees with what Sun and IBM ship.

[01:08:00.0000] <zcorpan>
why does it matter how many replacement characters there are?

[01:08:01.0000] <hsivonen>
zcorpan: dunno. over eager "interop" consistency I guess

[01:09:00.0000] <annevk>
the suggestion is to leave the decoding charistics up to the decoding specs

[01:09:01.0000] <annevk>
/me thinks that make sense

[01:09:02.0000] <zcorpan>
we should know when to stop... :) we probably can't get 100% interop anyway, and going there might cost more than it's worth

[01:10:00.0000] <hsivonen>
jgraham: did you already take a look at doing both error reporting and recovery at the same time using Python codecs?

[01:10:01.0000] <annevk>
zcorpan, we should get a reasonable baseline implemented

[01:11:00.0000] <hsivonen>
/me notes that getting both error reporting and recovery at the same time required a custom replacement for java.io.InputStreamReader and the code becomes hairy fast

[01:11:01.0000] <annevk>
and continue our quest from there

[01:11:02.0000] <zcorpan>
annevk: agreed

[01:11:03.0000] <annevk>
for the holy grail of interop

[01:12:00.0000] <zcorpan>
actually, now that i've drafted that text, i think http://lists.w3.org/Archives/Public/www-style/2006Oct/0140.html is more appropriate

[01:12:01.0000] <hsivonen>
annevk: I don't have an AtheistParseError and the html5lib tests don't appear to have it. Can we remove it from the test format spec?

[01:13:00.0000] <hsivonen>
annevk: AtheistParseError was reporting />, right?

[01:13:01.0000] <annevk>
yeah

[01:13:02.0000] <annevk>
lets kill that joke

[01:13:03.0000] <hsivonen>
/me edits the wiki

[01:14:00.0000] <jruderman>
i missed an atheism joke? darn

[01:15:00.0000] <hsivonen>
so there are 13 JSON implementations for Java and I didn't find even one where I couldn't detect some suckiness straight from the docs

[01:18:00.0000] <hsivonen>
I mean why oh why do they wrap a Sun-provided collection class behind a getter instead of making the wrapper implement the corresponding collection interface and delegating to the wrapped collection?

[01:18:01.0000] <hsivonen>
bah.

[01:20:00.0000] <othermaciej>
hi everyone

[01:20:01.0000] <hsivonen>
hi

[01:21:00.0000] <othermaciej>
how's the exciting world of HTML?

[01:25:00.0000] <hsivonen>
othermaciej: turns out that tokenization changed substantially while I was away :-)

[01:26:00.0000] <othermaciej>
hsivonen: well that's exciting :-)

[01:31:00.0000] <hsivonen>
annevk: fwiw, it appears that the html5lib test case format ignores attributes on the end tag after all

[01:31:01.0000] <annevk>
the tokenizer tests?

[01:31:02.0000] <annevk>
could be

[01:31:03.0000] <hsivonen>
annevk: yes

[01:32:00.0000] <annevk>
I guess we're "dropping" them in the test harness

[01:32:01.0000] <annevk>
which makes the tests more reusable I suppose

[01:32:02.0000] <hsivonen>
I implemented reporting attributes on the end tag token

[01:33:00.0000] <hsivonen>
I guess attributes on the end tag are sufficiently rare that I shouldn't bother writing branches for omitting them in the tokenizer

[01:33:01.0000] <hsivonen>
I have a general empty attributes optimization anyway

[01:36:00.0000] <Hixie>
i agree that we shouldn't define it beyond what is there now, for the FFFD cases

[01:41:00.0000] <annevk>
"I've looked at how Safari renders shadows - the spec should probably define something similar, since it works and it's not insane or anything." :)

[01:44:00.0000] <zcorpan>
an implementation that is not insane, wow, that's not too common ;)

[01:48:00.0000] <annevk>
hmm

[01:49:00.0000] <annevk>
so what happens when I do createElement("isindex") and insert it and then request innerHTML

[01:49:01.0000] <annevk>
they may be macros, but they can be inserted by other means than the parser...

[01:49:02.0000] <annevk>
same for "image" and "keygen"

[01:50:00.0000] <Hixie>
if you createElement isindex you get nothing useful

[01:50:01.0000] <Hixie>
same as createElement('bogus')

[01:50:02.0000] <Hixie>
same with image and keygen

[01:51:00.0000] <annevk>
so you get <image>foobar</image> (if I created some child node "foobar") back from innerHTML for instance?

[01:51:01.0000] <annevk>
I suppose that's fine

[01:51:02.0000] <Hixie>
what do browsers do?

[01:52:00.0000] <annevk>
not all browsers treat these things as parser macros

[01:52:01.0000] <annevk>
so I expect them to differ a lot

[01:52:02.0000] <othermaciej>
you can't createElement a keygen element?

[01:52:03.0000] <othermaciej>
I think you can in Safari

[01:52:04.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20HTML%3E%3Cbody%3E%3Cscript%3Edocument.body.appendChild%28document.createElement%28%27image%27%29%29%3B%3C/script%3E

[01:52:05.0000] <othermaciej>
dunno about isindex or image

[01:52:06.0000] <Hixie>
image seems to turn into img in all but firefox

[01:53:00.0000] <othermaciej>
yeah, I get an img there

[01:53:01.0000] <annevk>
/me too

[01:53:02.0000] <othermaciej>
createElement('keygen') also does the expected thing

[01:53:03.0000] <annevk>
Can someone please submit a spec for "keygen"?

[01:53:04.0000] <zcorpan>
firefox returns <image> for innerHTML, not <image></image>

[01:53:05.0000] <othermaciej>
annevk: we just reverse-engineered it as best we could from Firefox and their docs

[01:54:00.0000] <othermaciej>
annevk: a full spec has to reference ASN.1 formats for the cert to submit and such :-(

[01:54:01.0000] <annevk>
you mean those Netscape docs on the web?

[01:54:02.0000] <othermaciej>
yeah

[01:54:03.0000] <annevk>
those are pretty terrible

[01:54:04.0000] <annevk>
IE7 gives <img>

[01:55:00.0000] <annevk>
<keygen></keygen> in IE7

[01:55:01.0000] <annevk>
<isindex> with nothing rendered

[01:55:02.0000] <Hixie>
ie7 doesn't do keygen

[01:55:03.0000] <othermaciej>
in Safari I get <keygen> with three <option> elements in it

[01:56:00.0000] <annevk>
oh, I forgot to type "obviously" there

[01:56:01.0000] <zcorpan>
othermaciej: same as firefox

[01:56:02.0000] <annevk>
othermaciej, interesting :)

[01:56:03.0000] <annevk>
/me thought Firefox used XBL

[01:56:04.0000] <othermaciej>
for 'isindex' I get the <isindex> element itself, but that's not what happens when we parse it directly

[01:56:05.0000] <zcorpan>
except firefox has two options

[01:56:06.0000] <zcorpan>
firefox uses xbl for isindex

[01:57:00.0000] <Hixie>
well anyway

[01:57:01.0000] <othermaciej>
in that case we get "<hr>This is a searchable index. Enter search keywords: <isindex type="khtml_isindex"><hr>

[01:57:02.0000] <othermaciej>
which is retarded

[01:57:03.0000] <Hixie>
not really worried about these three elements much

[01:57:04.0000] <othermaciej>
actually, all that wrapped in a <div>

[01:57:05.0000] <othermaciej>
<keygen> is used on some vaguely critical sites

[01:57:06.0000] <othermaciej>
we didn't add it just for entertainment

[01:57:07.0000] <annevk>
yeah, <keygen> is important

[01:58:00.0000] <othermaciej>
though it's true that it is not commonly used overall

[01:58:01.0000] <zcorpan>
those sites use activex for ie, right?

[01:58:02.0000] <othermaciej>
yes

[01:58:03.0000] <annevk>
yup

[02:00:00.0000] <Hixie>
i'm happy to do whatever for  <keygen> if someone can spec it

[02:01:00.0000] <Fuzzy76>
just Google "keygen", you're bound to find something useful ;)

[02:01:01.0000] <annevk>
not really ;)

[02:01:02.0000] <Hixie>
sadly not

[02:02:00.0000] <othermaciej>
http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503

[02:02:01.0000] <annevk>
the most useful documentation are the implementations of WebKit and Gecko I'm afraid (because they're open source)

[02:02:02.0000] <othermaciej>
but it's hard to interpret the details of how the key is encoded

[02:03:00.0000] <othermaciej>
in WebKit, some aspects of how the generated cert is encoded are not open source (not because we consider them top seekrit but because they use private interfaces to Apple libraries, to our chagrin)

[03:26:00.0000] <annevk>
People want the <s> element in HTML5 to be conforming

[03:27:00.0000] <Hixie>
they do?

[03:27:01.0000] <annevk>
Use case given: "Marking up the implied meaning by striking out has gotten very popular in the past two years among <s>lazybones and exhibitionists</s> bloggers and diary posters."

[03:27:02.0000] <annevk>
I got an e-mail from someone from Russia and apparently it's quite popular there

[03:27:03.0000] <Hixie>
isn't <del> better for that?

[03:27:04.0000] <annevk>
Yeah, I guess

[03:28:00.0000] <othermaciej>
does <del> have a default presentation of strikethrough?

[03:28:01.0000] <othermaciej>
(looks like yes)

[03:30:00.0000] <annevk>
There's also <strike>

[03:45:00.0000] <annevk>
nice response on molly.com BenWard

[03:45:01.0000] <BenWard>
Thank you :)

[06:17:00.0000] <annevk>
"<s> does not mean that content is subject for removing. The content was

[06:17:01.0000] <annevk>
marked up with <s> at the same exact moment it was created; it was

[06:17:02.0000] <annevk>
purposedly marked up like that. It's like when you say "A, err... I mean

[06:17:03.0000] <annevk>
B", and you said A not because you have mistaken, but because you were

[06:17:04.0000] <annevk>
really wanting to say it like that - a, err..., i mean b."

[06:18:00.0000] <annevk>
I think it's sort of a valid use case

[06:18:01.0000] <annevk>
It would also apply to the earlier given example

[06:18:02.0000] <zcorpan>
i think del should be defined to be appropriate for such cases... :)

[06:19:00.0000] <annevk>
That would work too

[06:21:00.0000] <Lachy>
bugzilla uses <s> for marking up links to bugs that are resolved (at least it did last time I checked)

[06:21:01.0000] <annevk>
yeah, there <del> would not appropriate I think

[06:22:00.0000] <zcorpan>
title="Resolved"

[06:22:01.0000] <zcorpan>
[title=Resolved] { text-decoration:strike-through }

[06:22:02.0000] <annevk>
no backpat?

[06:22:03.0000] <zcorpan>
what's the compat problem?

[06:22:04.0000] <annevk>
legacy UAs

[06:22:05.0000] <zcorpan>
that don't support attribute selectors?

[06:23:00.0000] <annevk>
for instance

[06:23:01.0000] <zcorpan>
the information is still there, if you hover the link you will get a tooltip

[06:24:00.0000] <Lachy>
looks like bugzilla has since been updated to use <span class="bz_closed"> and other similar classes

[06:24:01.0000] <zcorpan>
using a class could solve the attribute selectors limitation

[06:25:00.0000] <annevk>
using <s> could solve all problems simpler

[06:26:00.0000] <zcorpan>
perhaps, but it doesn't really mean "resolved", does it?

[06:26:01.0000] <annevk>
it means "less relevant"

[06:26:02.0000] <zcorpan>
a reader could figure it out though

[06:27:00.0000] <zcorpan>
ok

[06:27:01.0000] <annevk>
or something in that direction

[06:27:02.0000] <Lachy>
if we add <s>, then who wants to volunteer to handle the huge backlash from those same people that object to <b>, <i>, etc?

[06:27:03.0000] <zcorpan>
/me doesn't

[06:29:00.0000] <zcorpan>
btw, i discussed with cerbera the other day about html5's suggested markup for different kinds if user input is very verbose and seems to be semantics for semantics' sake

[06:29:01.0000] <zcorpan>
nested kbd/samp doesn't help the reader understand the text better

[06:29:02.0000] <zcorpan>
and UAs probably can't do anything useful with the information

[06:29:03.0000] <hsivonen>
/me nods

[06:30:00.0000] <zcorpan>
i've tried to style the proposed markup with css but even that doesn't really help. for styling it is better to have a class on the outermost element

[06:31:00.0000] <Lachy>
zcorpan, yeah, that sections really just more like suggested conventions for authors, rather than something useful for consumers

[06:31:01.0000] <Lachy>
that's why we need parent selectors! ;-)

[06:32:00.0000] <zcorpan>
in the wild, <kbd> is already used for at least keys that the user is to press

[06:32:01.0000] <hsivonen>
Lachy: why are the conventions useful for authors except for self-congratulation about semantics?

[06:32:02.0000] <Lachy>
hsivonen, I never said they were useful

[06:33:00.0000] <hsivonen>
Lachy: ah. just conventions :-)

[06:34:00.0000] <zcorpan>
perhaps kbd can be defined to mean any kind of user input, e.g. text that the user is to type, or keys the user is to press, or menu items the user is to follow

[06:34:01.0000] <hsivonen>
/me checks out molly.com and is surprised

[06:35:00.0000] <Lachy>
in general, coding conventions are useful, particularly in collaborative environments, but when it comes to purely semantic conventions with little practical purpose, doesn't seem useful at all

[06:35:01.0000] <zcorpan>
indeed

[06:35:02.0000] <zcorpan>
<kbd><kbd><samp> is just extremely verbose

[06:36:00.0000] <Lachy>
<kbd><kbd>Alt</kbd>+<kbd>F4</kbd></kbd> is a useful convention since it allows for easy styling of individual keys

[06:36:01.0000] <zcorpan>
<kbd>Alt</kbd>+<kbd>F4</kbd>

[06:36:02.0000] <zcorpan>
seems enough to me

[06:36:03.0000] <annevk>
hmm

[06:37:00.0000] <annevk>
you might want to style them as block...

[06:37:01.0000] <Jero>
/me agrees with zcorpan

[06:37:02.0000] <Lachy>
it depends if you want your stylesheet to distinguish between text to enter and sequences of keys to press

[06:37:03.0000] <annevk>
/me follows the spec already

[06:37:04.0000] <annevk>
so I'm prolly biased

[06:38:00.0000] <zcorpan>
Lachy: perhaps. though classes can be used

[06:38:01.0000] <Lachy>
e.g. giving instructions like this to users: "Enter "<kbd>format C:</kbd>" and then press <kbd><kbd>Enter</kbd></kbd>.

[06:38:02.0000] <hsivonen>
here's something for a potentially rathole sematic debate: If you have a file system path or a URI on a Web page, should it have specific markup and if yes, which?

[06:39:00.0000] <hsivonen>
semantic

[06:39:01.0000] <Lachy>
hsivonen, I use <code> for both

[06:39:02.0000] <annevk>
/me uses <code> for URIs

[06:40:00.0000] <annevk>
/me isn't sure why

[06:40:01.0000] <Lachy>
... just to get a monospace font

[06:40:02.0000] <zcorpan>
tt, anyone? :)

[06:41:00.0000] <Lachy>
one could possibily argue that <a>http://...</a> is the right markup

[06:41:01.0000] <annevk>
without href?

[06:41:02.0000] <annevk>
hmm

[06:42:00.0000] <annevk>
that'd be wrong actually

[06:42:01.0000] <Lachy>
either with or without.  It depends i

[06:42:02.0000] <Lachy>
yeah, it'd be wrong with the current HTML5 definition

[06:49:00.0000] <Jero>
hmm, why should an HTML5 parser close the first a element right after the closing tag of the first table element with test #30 on http://jero.net/lab/ph5p/tests.html ???

[06:49:01.0000] <Jero>
that's what html5lib does anyway

[06:50:00.0000] <Jero>
http://hasather.net/html5/parsetree/parsetree?source=%3Ca%3E%3Ctable%3E%3Ctd%3E%3Ca%3E%3Ctable%3E%3C%2Ftable%3E%3Ca%3E%3C%2Ftr%3E%3Ca%3E%3C%2Ftable%3E%3Cb%3EX%3C%2Fb%3EC%3Ca%3EY

[06:51:00.0000] <annevk>
it needs to reopen because it hits some other <a> element

[06:52:00.0000] <zcorpan>
you mean why does it result in "...</table></a><a><b>..." as opposed to just "...</table><b>..."?

[06:53:00.0000] <Jero>
exactly

[06:53:01.0000] <zcorpan>
perhaps it's a bug in html5lib -- what does the spec say? :)

[06:55:00.0000] <Jero>
can't find anything in the spec, but doesn't seem very logical to close an a element after a table element or before a b element

[07:05:00.0000] <zcorpan>
Cerbera: welcome :)

[07:05:01.0000] <Cerbera>
hi :)

[07:06:00.0000] <Cerbera>
(Opera's IRC is much prettier than mIRC)

[07:08:00.0000] <zcorpan>
Cerbera: see logs from 14:37 for the kbd discussion

[07:09:00.0000] <Cerbera>
zcorpan: I read from <http://krijnhoetmer.nl/irc-logs/whatwg/20070615#l-294>

[07:10:00.0000] <Cerbera>
In making websites, I have yet to need more than one level of <kbd> for styling or any other purpose

[07:11:00.0000] <zcorpan>
yeah

[07:11:01.0000] <Cerbera>
I think styling is the only purpose for that element, in practise.

[07:12:00.0000] <zcorpan>
good enough reason to keep it around :)

[07:13:00.0000] <Cerbera>
yes, me too. but it doesn't need to be nested in practise

[07:13:01.0000] <hsivonen>
gaah. I chose a JSON impl that can take a byte stream so that it could handle encodings per spec. Does it? Nooo.

[07:14:00.0000] <zcorpan>
hsivonen: bad luck :)

[07:16:00.0000] <Cerbera>
so if <kbd>foo</kbd> is adequate for styling purposes, why make its semantics more specific so they require extra levels?

[07:16:01.0000] <Cerbera>
as I said to zcorpan yesterday: "it's not like double-clicking styled text is going to start up an external application and perform that action"

[07:17:00.0000] <hsivonen>
jgraham: what's the logic in tokenizer test character coalescing?

[07:18:00.0000] <zcorpan>
Cerbera: you wanna summarize the information here and send to the list? :)

[07:18:01.0000] <hsivonen>
Why are there two tokens here:

[07:18:02.0000] <hsivonen>
Expected tokens:

[07:18:03.0000] <hsivonen>
["ParseError",["Character","&"],["Character","f"]]

[07:18:04.0000] <Cerbera>
zcorpan: yeah

[07:19:00.0000] <Cerbera>
zcorpan: although I'm supposed to be doing work :P

[07:19:01.0000] <zcorpan>
me too :)

[07:24:00.0000] <Cerbera>
so then: 1) UAs can't do anything with the information. For starters, the application it's for isn't declared.

[07:25:00.0000] <Cerbera>
2) a single level of either <kbd> or <samp> is enough for common styling needs

[07:27:00.0000] <Cerbera>
3) it's much more convenient to write '<kbd>File</kbd> > <kbd>Exit</kbd>' than '<kbd><kbd><samp>File</samp></kbd> > <kbd><samp>Exit</samp</kbd></kbd>'

[07:28:00.0000] <Cerbera>
4) fiddly markup inevitably causes confusion and is written wrongly (is that a legitimate comment?)

[07:29:00.0000] <Cerbera>
(case in point: my example was wrong! missing > at the end of a </samp>)

[07:34:00.0000] <zcorpan>
that about sums it up, although it's good to put forward the counter arguments too (allows for different styling)

[07:35:00.0000] <Cerbera>
5) people can nest the elements if they like (e.g. for more complex styling) without this being required

[07:40:00.0000] <Cerbera>
are there any there any other arguments for keeping it?

[07:42:00.0000] <zcorpan>
not afaict

[07:43:00.0000] <Cerbera>
perhaps some feel it adds clarity to the intention markup by being more specific?

[07:46:00.0000] <zcorpan>
only for people who have read the spec and is peeking at the source code when reading a web page

[07:47:00.0000] <Cerbera>
yeah, like content authors. I'm havn't seen it suggested, though.

[07:48:00.0000] <Cerbera>
the context of the sentence would make clear what type if input is being talked about, I suppose

[07:48:01.0000] <zcorpan>
yeah

[07:48:02.0000] <Cerbera>
ok, looks like 1-5 sums it up (perhaps better written)

[10:45:00.0000] <met_>
XXXHTML5 is comming http://kecy.roumen.cz/roumingShow.php?file=titstag.jpg

[10:59:00.0000] <Jero>
<fake/>

[12:10:00.0000] <csarven->
what is the plan for replacing (if at all) <acronym> ?

[12:10:01.0000] <Hixie>
it's gone

[12:10:02.0000] <Hixie>
<abbr> replaces it

[12:12:00.0000] <csarven->
aren't abbreviation and acronym different things? is acronym a subset of abbr?

[12:15:00.0000] <Hixie>
there are many things similar to abbreviations and acronyms, with overlapping definitions

[12:15:01.0000] <Hixie>
it depends on the language, on the culture

[12:15:02.0000] <Hixie>
and there seems to be no really good reason to have more than one element

[12:15:03.0000] <Hixie>
so we have just one element that covers the concept "one piece of text standing for another piece of text"

[12:16:00.0000] <csarven->
gotcha

[12:16:01.0000] <csarven->
although i dont see this approach being applied to the new spec

[12:16:02.0000] <csarven->
at least not entirely

[12:17:00.0000] <Hixie>
any specifics in mind?

[12:17:01.0000] <csarven->
<m>

[12:18:00.0000] <Hixie>
<m> is an interesting one, in that there are other elements that could arguably have the same presentation, but they don't really have the same semantics

[12:18:01.0000] <Hixie>
<b>, for instance

[12:18:02.0000] <Hixie>
(we added <m> before we added <b>)

[12:19:00.0000] <csarven>
i never understood the 'semantics' behind <m> when it acts nothing more then a <span> for instance

[12:20:00.0000] <Hixie>
the semantics are "highlight this part of text", for example highlighting the search keywords in google cache

[12:21:00.0000] <csarven>
<span class="highlight"> ? (im not fully uptodate, so correct my if im wrong but are predefined classnames gone?)

[12:21:01.0000] <bewes1>
they are gone, yeah

[12:21:02.0000] <Hixie>
<span class="highlight"> is the same, semantically, as <span>

[12:21:03.0000] <Hixie>
which is the same as not having anything at all

[12:22:00.0000] <Hixie>
don't forget stylesheets are optional, if you're using a stylesheet to convey meaning, you're doing it wrong

[12:22:01.0000] <csarven>
how would <m> render on a UA that supports no stylesheets?

[12:22:02.0000] <Hixie>
e.g. lynx could render it as black text on a yellow background

[12:23:00.0000] <othermaciej>
some non-CSS UAs still have default presentation for various elements

[12:23:01.0000] <csarven>
isn't that also conveying information by presentation?

[12:23:02.0000] <Hixie>
all information is conveyed by presentation

[12:24:00.0000] <Hixie>
at the end of the day

[12:24:01.0000] <Hixie>
the key is that the _exact_ presentation doesn't matter

[12:24:02.0000] <csarven>
how would a screenreader interpret <m> ?

[12:24:03.0000] <Hixie>
e.g. it could be a blue background. or yellow text. or italics. or it could sing a jingle before and after.

[12:24:04.0000] <Hixie>
it could be louder, it could play an audio icon

[12:25:00.0000] <Hixie>
or it could not render them differently at all, but allow the user to jump to each <M>

[12:25:01.0000] <Hixie>
which might be more helpful

[12:27:00.0000] <Hixie>
the point about stylesheets is that the meaning should be conveyed to the _browser_ without forcing a particular presentation, and then the _browser_ can make the presentation choice

[12:27:01.0000] <Hixie>
in the case of CSS browsers, that choice might be based heavily on the provided stylesheet

[12:28:00.0000] <Hixie>
but it doesn't have to be, e.g. CSS browsers make <h1> bigger than <h2> even if you don't tell them to

[12:28:01.0000] <csarven>
i think i see it a bit more clearer now.. originally i had doubts about <m>. if i understand you correctly, the purpose of <m> is to show a relationship between an action that was taken previously in context of the current document

[12:28:02.0000] <Hixie>
well, specifically it just marks a run of text as being marked or highlighted, it doesn't constrain the reason for that marking or highlighting

[12:29:00.0000] <Hixie>
the use case that was primarily in mind when we added it was the way google cache (e.g.) highlights search terms, or the way many scripts highlight google search terms when you go to their site

[12:30:00.0000] <csarven>
right but it goes beyond that and to highlight any text in the document. originally this was the part i couldn't quite agree with as highlighting can be done in various ways depending on context and the semantics behind it

[12:30:01.0000] <annevk>
If people start using them for anything but search terms I wonder if <m> will still be useful...

[12:30:02.0000] <Hixie>
the use of the word "highlight" in the spec may be a poor choice, i'm not sure exactly what term to use

[12:31:00.0000] <csarven>
signify/outline?

[12:31:01.0000] <Hixie>
it may also be that <m> isn't different enough from <strong>, and we may have to remove it

[12:32:00.0000] <Hixie>
(e.g. another case for highlighting is when you're revising material and you want to highlight the key parts of the text -- but are the key parts of the text not just the "important" parts? meaning <strong>?)

[12:32:01.0000] <csarven>
right.. for instance, wouldn't non-css UAs be able to jump to each <strong> (regardless of a search result)

[12:32:02.0000] <Hixie>
well, they could, but would it work as well? i don't know

[12:32:03.0000] <Hixie>
maybe i should use the term "key parts of the text" to define <M>

[12:33:00.0000] <csarven>
then i suppose knowing the real difference between <m> and <strong> would be noteworthy

[12:33:01.0000] <annevk>
"within a specific context" too

[12:33:02.0000] <annevk>
they're only key parts if you previously searched for them, for instance

[12:33:03.0000] <Dashiva>
And what happens if there's an <m> in the text already?

[12:33:04.0000] <csarven>
in the case of a action taken previously i can understand 'within a specific context' but if used to 'highlight' a part of the document, im not sure if its accurate

[12:34:00.0000] <annevk>
Dashiva, that and hiliting "foobar" in "foo<a>barbaz</a>" are interesting questions

[12:47:00.0000] <jgraham>
annevk: There's two n's in Connolly (Re: HTML4/HTML5 differences)

[12:49:00.0000] <jgraham>
Also, I think that instead of just lists of dropped elements / attributes it would be good to say what they are replaced with (where relevant) and group them if appropriate

[12:50:00.0000] <jgraham>
e.g. The following elements are dropped because they are presentational and CSS should be used instead: big, center, etc. 

[12:52:00.0000] <jgraham>
I should really mail this sort of thing...

[12:54:00.0000] <Hixie>
woah, IE parses entities in attributes and in content differently

[12:57:00.0000] <jgraham>
/me cries

[12:58:00.0000] <jgraham>
Really?

[12:58:01.0000] <jgraham>
Fun...

[13:44:00.0000] <Hixie>
wow

[13:45:00.0000] <Hixie>
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0014.html

[13:45:01.0000] <billmason>
Oh, this is going to be good.

[13:45:02.0000] <Hixie>
"Just to clarify, we firmly believe that Iraq has Weapons of Mass Destruction."

[13:45:03.0000] <billmason>
lol

[13:47:00.0000] <Hixie>
or "Just to clarify, we do not believe that Guantanamo Bay is terribly different from any other jail. And it does not use a different legal system."

[13:47:01.0000] <billmason>
And here I was thinking that the fight over who gets to keep their name wins -- XHTML5 or 2 -- was going to be the hard part.

[13:47:02.0000] <Hixie>
this whole discussion is somewhat moot

[13:48:00.0000] <Hixie>
it doesn't matter if XHTML2 uses the HTML namespace

[13:48:01.0000] <Hixie>
it's not like there's ever going to be XHTML2 content to clash with the HTML5 content

[13:48:02.0000] <Hixie>
in fact, making them use the same nameaspce is the most effective way to guarentee that, since it makes it practically impossible for browsers to implement both

[13:49:00.0000] <Hixie>
and it's not like they can't implement HTML

[13:49:01.0000] <Hixie>
the name is also somewhat academic. it's clear to anyone not involved in XHTML2 that the XML version of HTML5 should be called XHTML5.

[13:50:00.0000] <Hixie>
just stands to reason

[13:50:01.0000] <Hixie>
anyway

[13:50:02.0000] <Hixie>
i'm sure this will all be resolved without my having to get involved

[13:50:03.0000] <billmason>
I don't disagree.  It just seemed like it would be just the thing to hit that emotional chord of debate endlessly.

[13:50:04.0000] <Hixie>
so i'll get on with the real work that matters :-)

[13:51:00.0000] <Hixie>
hey if it distracts people from camplaining about the spec :-P

[13:51:01.0000] <billmason>
heh  :)

[13:52:00.0000] <Hixie>
lunch time

[13:52:01.0000] <Hixie>
bbl

[13:57:00.0000] <Dashiva>
Maybe they're trying to make it impossible so they can say "It's not our fault, the browsers refused to implement"

[13:57:01.0000] <webben>
XHTML for HTML5 has never made sense to me, not least because I don't recall anybody being able to explain what the X stands for.

[13:58:00.0000] <webben>
whereas I at least understand what the X stands for and means in the case of XHTML2

[13:58:01.0000] <webben>
(being related to XHTML modularization)

[13:59:00.0000] <webben>
I can't see any gains to reusing the name to the HTML-next effort.

[13:59:01.0000] <webben>
It just courts controversy and will clearly cause confusion.

[14:01:00.0000] <webben>
even in XHTML2 didn't exist, i don't think XHTML5 would be an especially helpful name

[14:01:01.0000] <webben>
I'd say a helpful name would actually have "XML" in.

[14:07:00.0000] <Dashiva>
XHTML means "HTML as XML" in any practical context

[14:08:00.0000] <webben>
Dashiva: "HTML as XML" isn't normally a "practical context".

[14:09:00.0000] <webben>
And in so far as it's a useful context, it's precisely because of extensibility not faciliated by HTML (viz. mixing XMLs: XForms, SVG, MathML)

[14:10:00.0000] <webben>
(generally speaking)

[14:12:00.0000] <webben>
While the idea that XHTML2 is similar to XHTML1.1 may appear odd at first sight, elements in the existing namespace actually do seem to have similar semantics: http://www.w3.org/TR/xhtml2/elements.html

[14:12:01.0000] <webben>
same with: http://www.w3.org/TR/xhtml2/attributes.html

[14:12:02.0000] <webben>
Like the HTML5 draft, XHTML2 also introduces loads of new stuff.

[14:13:00.0000] <webben>
but without any particular commitment to backwards compatibility

[14:13:01.0000] <webben>
i'm not sure how backwards compatibility with UAs relates to the same with namespaces however

[14:14:00.0000] <webben>
and there are now DTDs for including role and property in XHTML1.1 

[14:14:01.0000] <webben>
(which are one of XHTML2's more controversial introductions)

[14:15:00.0000] <othermaciej>
what's property?

[14:15:01.0000] <othermaciej>
there's a property attribute?

[14:15:02.0000] <othermaciej>
please tell me you're kidding

[14:16:00.0000] <webben>
Dashiva: It's perhaps also important to note that in so far as it is used, XHTML is largely served as text/html ... and usually wouldn't validate as XML

[14:16:01.0000] <webben>
othermaciej: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_property

[14:16:02.0000] <othermaciej>
great, as if the terms "property" and "attribute" weren't confusing enough

[14:17:00.0000] <webben>
othermaciej: http://www.w3.org/TR/aria-state/

[14:17:01.0000] <webben>
Dashiva: I therefore in "practical contexts" XHTML doesn't mean HTML as XML.

[14:19:00.0000] <webben>
othermaciej: Feel free to suggest a less confusing alternative name to such a generic attribute, but property already has implementations.

[14:30:00.0000] <othermaciej>
webben: my level of interest in "role" and "property" is pretty low, so no thanks

[14:38:00.0000] <Hixie>
webben: XHTML means "XML serialisation of HTML"

[14:38:01.0000] <webben>
Hixie: In what sense of "means"?

[14:39:00.0000] <webben>
(and for who?)

[14:39:01.0000] <webben>
it doesn't stand for that, and doesn't mean that in the world of the everyday web

[14:40:00.0000] <webben>
plus the XHTML 1.0 specification allows XHTML that wouldn't parse as XML

[14:41:00.0000] <webben>
when serving as text/html

[14:41:01.0000] <webben>
thanks to the general craziness that is Appendix C

[14:41:02.0000] <Hixie>
webben: "stands for"

[14:41:03.0000] <Hixie>
webben: "is short for"

[14:42:00.0000] <Hixie>
(i'm talking about XHTML5 and HTML5, specifically)

[14:42:01.0000] <Hixie>
i don't think the XHTML 1.0 specification _allows_ XHTML that wouldn't parse as XML

[14:42:02.0000] <Hixie>
i think it has encouraged it, but it's still not _allowed_

[14:44:00.0000] <webben>
ah okay, that sounds round

[14:44:01.0000] <webben>
*right

[14:45:00.0000] <webben>
still, it does make the acronym stand for something new

[14:45:01.0000] <webben>
and it doesn't really help people trying to understand what it is

[14:46:00.0000] <webben>
(which is what names should ideally do)

[14:46:01.0000] <Hixie>
i don't think the expansion really matters to be honest

[14:46:02.0000] <Hixie>
it's just a label

[14:46:03.0000] <webben>
acronyms are pernicious

[14:46:04.0000] <Hixie>
put it this way

[14:47:00.0000] <Hixie>
if XHTML2 didn't exist, we wouldn't even be having this discussion

[14:47:01.0000] <Hixie>
so the name XHTML5, in and of itself, is fine

[14:48:00.0000] <Hixie>
it's only the existence of this new language, which is similar to XHTML1 but is not a direct descendant of it, which is causing any naming issues at all

[14:48:01.0000] <webben>
well, it's opaque ... it's just that the existence of the label already with a different (and confusing already) meaning makes one question whether the label is a good one in the first place

[14:49:00.0000] <Hixie>
what do you think XHTML stands for?

[14:49:01.0000] <webben>
Hixie: Not only. The fact that a lot of the web is pseudo-XHTML is equally important.

[14:49:02.0000] <webben>
extensible

[14:50:00.0000] <Hixie>
how is XHTML1 extensible?

[14:50:01.0000] <webben>
XHTML1 isn't. XHTML is (through modularization).

[14:50:02.0000] <webben>
but the point isn't whether XHTML is a good name for what is currently called XHTML

[14:50:03.0000] <webben>
(it isn't in practice, probably)

[14:51:00.0000] <webben>
but whether adding yet more confusion to the mix helps clear things up

[14:51:01.0000] <othermaciej>
XHTML1 is in theory extensible via content in non-HTML namespaces

[14:51:02.0000] <webben>
(which it doesn't, it seems to me)

[14:51:03.0000] <othermaciej>
(I guess that is a possible sense of "extensible")

[14:51:04.0000] <Hixie>
i don't understand how m12n does anything to make XHTML extensible. also XHTML existed and was named long before xhtml m12n existed. so i don't buy that that's what it meant.

[14:51:05.0000] <webben>
othermaciej: Then it wouldn't be XHTML1 anymore, I think. Though it might use the XHTML namespace.

[14:51:06.0000] <Hixie>
webben: it's not clear to me that calling it something else would cause any less confusion.

[14:51:07.0000] <othermaciej>
the XML serialization of HTML5, whatever you may call it, needs to use the same namespace as XHTML1 for compatibility

[14:52:00.0000] <othermaciej>
XHTML2 does not have compatibility as a goal, so they have no need to use the same namespace

[14:52:01.0000] <webben>
othermaciej: compatibility with what?

[14:52:02.0000] <othermaciej>
and indeed putting an incompatible language in the same namespace is bogus

[14:52:03.0000] <webben>
othermaciej: surely anyone worried about that sort of compatibility would use the text/html serialization?

[14:52:04.0000] <othermaciej>
webben: deployed application/xhtml+xml content

[14:53:00.0000] <webben>
othermaciej: Ah. I see what you mean.

[14:53:01.0000] <Hixie>
othermaciej: see that e-mail i cited, it's what they're doing

[14:53:02.0000] <othermaciej>
which is a small amount but not 0, and I see no good reason to break it

[14:53:03.0000] <webben>
othermaciej: Why not just handle that with error correction?

[14:54:00.0000] <othermaciej>
webben: I don't see how the differences between XHTML2 and XHTML can be handled by error correction

[14:54:01.0000] <webben>
othermaciej: no ... i meant XHTML5 could use a different namespace, and the WHATWG spec could define how UAs should handle XHTML from the original namespace

[14:54:02.0000] <webben>
(as part of its general error handling)

[14:55:00.0000] <Hixie>
that doesn't fit our backwards compatibility design constraints

[14:55:01.0000] <webben>
othermaciej: I'm not really talking about XHTML2 ... I don't understand why they even want the same namespace.

[14:55:02.0000] <Hixie>
(our design goal is that you be able to take any existing content, and add stuff to it, and have that stuff work, without having to worry about changing namespaces, syntax, doctypes, whatever)

[14:56:00.0000] <webben>
Hixie: It's fine for reading existing content, and the spec discourages creating new XHTML content, /and/ anyone who cared about backwards compatibility would be using text/html, wouldn't they?

[14:56:01.0000] <webben>
which would mean they're already relying on error correction

[14:56:02.0000] <Hixie>
actually it doesn't discourage that anymore

[14:56:03.0000] <Hixie>
iirc

[14:56:04.0000] <webben>
oh

[14:56:05.0000] <othermaciej>
webben: if ECMAScript code in the page depends on the XHTML elements being in the XHTML namespace, I don't see how we can fix that with "error correction"

[14:57:00.0000] <webben>
othermaciej: I don't see why one would want to.

[14:57:01.0000] <Hixie>
want to what?

[14:57:02.0000] <Hixie>
it's not clear to me what you're proposing

[14:57:03.0000] <Hixie>
anyway

[14:57:04.0000] <Hixie>
time to reverse engineer DOCTYPE parsing

[14:58:00.0000] <webben>
fix ECMAScript depending on XHTML elements being in the XHTML namespace to not depend on XHTML elements being in the XHTML namespace

[14:58:01.0000] <webben>
sounds like a job for the authors of the original scripts to take up if they happen to want to

[14:59:00.0000] <Hixie>
well if we didn't do that, but we changed the namespace, the scripts would break

[14:59:01.0000] <webben>
Hixie: Why would you need to change the namespace for existing content declared to be in the old namespace?

[15:00:00.0000] <webben>
one might as well respect namespace declarations

[15:00:01.0000] <Hixie>
so why are we inventing a new namespace?

[15:00:02.0000] <Hixie>
i'm very confused as to what you're proposing

[15:00:03.0000] <webben>
I guess I'm very confused as to why folks thing XHTML2 reusing the existing namespace is bad, and XHTML5 reusing it is good.

[15:01:00.0000] <webben>
*why folks think

[15:01:01.0000] <gsnedders>
webben: XHTML2 breaks backwards compatibility. XHTML5 does not.

[15:01:02.0000] <Hixie>
if XHTML2 was going to actually be used, then it would be bad to reuse the namespace because it defines elements as having entirely different conformance rules

[15:01:03.0000] <othermaciej>
webben: how are they supposed to know which namespace to use?

[15:02:00.0000] <othermaciej>
document.createElementNS("http://www.w3.org/1999/xhtml", "div")

[15:02:01.0000] <webben>
othermaciej: who is they?

[15:02:02.0000] <gsnedders>
webben: as XHTML5 is backwards compatible with XHTML1, XHTML1 parsers can cope with XHTML5 (to a certain extent)

[15:02:03.0000] <gsnedders>
webben: implementations

[15:02:04.0000] <othermaciej>
what's the version of that that works when processed as XHTML1, or under a hypothetical new XHTML5 namespace?

[15:02:05.0000] <Hixie>
e.g. if <input> in XHTML1 is an HTMLInputElement DOM node, and <input> in XHTML2 is an XForms <input>, then there's no way a browser could know what to do when it found an <input> element

[15:02:06.0000] <webben>
gsnedders: I can't understand why that would be useful though.

[15:03:00.0000] <gsnedders>
webben: I can create an XHTML5 document that will work with already existing XHTML implementations.

[15:03:01.0000] <gsnedders>
webben: I don't need to wait for implementations to be updated.

[15:03:02.0000] <webben>
gsnedders: But why are you creating an XHTML document in the first place?

[15:03:03.0000] <webben>
is this for use of MathML? SVG?

[15:04:00.0000] <othermaciej>
gsnedders: implementations are going to handle existing application/xhtml+xml content that's authored as XHTML 1.0 or 1.1 in the future as XHTML5

[15:04:01.0000] <othermaciej>
gsnedders: scripts in those documents need to keep working

[15:04:02.0000] <othermaciej>
gsnedders: therefore the namespace URI needs to be the same

[15:04:03.0000] <gsnedders>
othermaciej: I know.

[15:04:04.0000] <othermaciej>
er

[15:04:05.0000] <othermaciej>
I meant htat for webben

[15:04:06.0000] <othermaciej>
webben: see above comments

[15:04:07.0000] <gsnedders>
othermaciej: I thought so :)

[15:05:00.0000] <Philip`>
I created an XHTML document once, because I had an XML serialiser available and I was too lazy to write an HTML serialiser, though I've not encountered any more compelling reasons myself

[15:05:01.0000] <webben>
othermaciej: I don't really see why the namespaced element creation is a problem.

[15:05:02.0000] <webben>
Philip`: My point was mainly that existing implementations don't do a good job of supporting the other XMLs that can be used with XHTML anyhow.

[15:06:00.0000] <jgraham>
There are people who actually use MathML and SVG, so this problem is not theoretical

[15:06:01.0000] <webben>
e.g. Mozilla and IE support MathML with extensions; the Mozilla one at any rate only supports presentational MathML. Opera doesn't support MathML except in the form of a user.js (and again only presentational.)

[15:06:02.0000] <gsnedders>
FWIW: http://digg.com/programming/HTML5_differences_from_HTML4

[15:07:00.0000] <othermaciej>
webben: existing documents will expect an "img" in the xhtml1 namespace to be an HTMLInputElement with associated presentation and semantics

[15:07:01.0000] <jgraham>
Mozilla MathML is built in (but you need fonts)

[15:07:02.0000] <othermaciej>
webben: I don't see how you can say it doesn't matter

[15:07:03.0000] <jgraham>
XForms is an extension

[15:07:04.0000] <othermaciej>
webben: unless you think all the elements should exist in both namespaces

[15:07:05.0000] <webben>
jgraham: Oh wait sorry. Yeah, you're right.

[15:07:06.0000] <othermaciej>
webben: in which case, dynamically constructing a document and serializing it would result in a frankenstein mish-mash of two different namespaces for the same elements

[15:08:00.0000] <Philip`>
(Oh, actually I've created at least two XHTML documents, and one could be considered XHTML5 since it had <canvas>, though the only reason for doing that was so that it'd break in IE and I still didn't have any actual good reasons to use XHTML)

[15:08:01.0000] <webben>
othermaciej: I'd have thought existing docs would expect an img with associated presentation and semantics defined by XHTML1 if they're using that namespace.

[15:08:02.0000] <webben>
othermaciej: not any new aspects defined by XHTML5

[15:09:00.0000] <gsnedders>
webben: yes, but XHTML5 is compatible with XHTML1.

[15:09:01.0000] <othermaciej>
webben: so you think existing application/xhtml+xml documents should be processed as XHTML1 instead of as XHTML5?

[15:09:02.0000] <Hixie>
webben: the rules in XHTML5 are a superset of the rules of XHTML1, the rules in XHTML2 are an overlapping set that contradict some of XHTML1's requirements.

[15:09:03.0000] <othermaciej>
and all the XHTML1 elements should be in two different namespaces?

[15:09:04.0000] <gsnedders>
webben: there's no mention of any version in the namespace anyway

[15:10:00.0000] <webben>
Hixie: Not even the elements in XHTML5 are a superset of those in XHTML1.

[15:10:01.0000] <webben>
(and same for XHTML2)

[15:10:02.0000] <Hixie>
webben: anything not yet defined in XHTML5 that is in XHTML1 will be defined in due course (though maybe not as part of the conforming language). anything in XHTML5 that *contradicts* XHTML1 is an error.

[15:10:03.0000] <gsnedders>
how many groups do namespace URIs goes through before being assigned?

[15:10:04.0000] <webben>
Hixie: I see.

[15:11:00.0000] <gsnedders>
(that is w3.org namespaces)

[15:11:01.0000] <Hixie>
gsnedders: just the director, i think

[15:11:02.0000] <webben>
Hixie: So XHTML5 will define semantics for <acronym> equivalent to those in XHTML1?

[15:11:03.0000] <othermaciej>
I don't think there has been a namespace priority dispute before

[15:11:04.0000] <gsnedders>
Hixie: what I thought. Which may mean whichever group applies to use it may get it.

[15:12:00.0000] <jgraham>
(see e.g. http://golem.ph.utexas.edu/~distler/blog/archives/001254.html for a IMHO good use of XHTML+SVG+MathML)

[15:13:00.0000] <webben>
jgraham: I'm not discouraging the use of XHTML+SVG+MathML or saying those things aren't used.

[15:13:01.0000] <Hixie>
webben: it'll define *processing requirements* for <acronym> equivalent to those in XHTML1 (and indeed already does)

[15:13:02.0000] <Hixie>
webben: however, it doesn't define "semantics" to elements that are not conforming

[15:14:00.0000] <webben>
Why not?

[15:14:01.0000] <Hixie>
gsnedders: in this particular case, it doesn't matter, since the namespace is already minted

[15:14:02.0000] <webben>
Hixie: Doesn't that mean implementors have to consult other specs/non-specs to find out what elements actually mean?

[15:14:03.0000] <jgraham>
" anyone who cared about backwards compatibility would be using text/html, wouldn't they?" - sort of implies people won't care if their XHTML breaks in the future

[15:15:00.0000] <gsnedders>
Hixie: namespace assignments is one section of the process I barely know. What happens when a WG wants to use an already minted one?

[15:15:01.0000] <Hixie>
webben: i guess we could briefly define semantics (as opposed to processing requirements, which is what browser vendors need) for elements that aren't conforming.

[15:15:02.0000] <Hixie>
gsnedders: they use it

[15:15:03.0000] <webben>
jgraham: I wasn't proposing WHATWG make breaking existing XHTML1 content a requirement of conforming to the HTML5 spec.

[15:15:04.0000] <gsnedders>
Hixie: shit.

[15:16:00.0000] <Hixie>
gsnedders: there really is no problem with xhtml2 using the xhtml namespace

[15:16:01.0000] <gsnedders>
Hixie: yes, but that's only due to the lack of implementors

[15:16:02.0000] <Hixie>
gsnedders: it's actually better than them using their own namespace, as it removes any doubt that someone might implement the spec (since it'd be impossible to implement both)

[15:16:03.0000] <gsnedders>
I'm more worried for the next time it happens, with two standards, both with major companies backing it and implementing it.

[15:16:04.0000] <webben>
Hixie: assistive UAs need semantics since they do much more interesting things with semantics than typical GUI UAs

[15:17:00.0000] <webben>
and in practice that means GUI UAs often need the semantics in order to work out how to expose content to accessibility frameworks

[15:17:01.0000] <Hixie>
gsnedders: groups that are actually competent at language design wouldn't make that mistake

[15:17:02.0000] <gsnedders>
Hixie: true.

[15:18:00.0000] <Hixie>
webben: i don't think it would make the slightest difference to TAs if we included the one-line definition of <acronym>'s semantics or not, in practice

[15:18:01.0000] <webben>
Hixie: It depends on how self-sufficient the spec is meant to be.

[15:19:00.0000] <webben>
and how much implementors are meant to continue to try and guess from existing content and other implementations and old specs

[15:21:00.0000] <webben>
Hixie: certainly helpful to people like Rosmaita and Raman writing their own aural CSS

[15:22:00.0000] <webben>
(or me, in fact, trying to design some kind of interface for Orca to simply define speech behaviours for different roles ... if I weren't familiar with HTML)

[15:23:00.0000] <Hixie>
webben: in practice, treating the elements that aren't conforming as having no semantics is fine from an accessibility point of view. so i'm not convinced it matters. the only elements i can think of off-hand that have non-trivial semantics and that aren't conforming are <dir> and <acronym>.

[15:23:01.0000] <Hixie>
webben: and in practice you can just treat them as the spec will say (handle <dir> like <ul> and <acronym> like <span>)

[15:23:02.0000] <webben>
Hixie: how does it make any sense to handle acronym like span?!?

[15:24:00.0000] <Hixie>
webben: you make the title="" attribute accessible and you're done.

[15:24:01.0000] <webben>
at the very least it should be handled like abbr

[15:24:02.0000] <Hixie>
webben: it's not like there are many pages using it.

[15:25:00.0000] <webben>
Hixie: Given the microformats people are trying to work out if they could use span with title to get around the accessibility problems of dumping data into abbr's title, that doesn't sound like a great idea at all.

[15:25:01.0000] <webben>
Hixie: And given that ATs have special handling for abbr and title, different to their handling for span and title.

[15:25:02.0000] <Hixie>
show me evidence that it'd be a problem and i might be convinced, but the evidence i've seen is that it wouldn't actually maatter

[15:26:00.0000] <Hixie>
note that many things that are problems in theory end up being non-issues in the real world

[15:26:01.0000] <webben>
Hixie: Usually because even bigger problems occlude them,

[15:26:02.0000] <webben>
Hixie: What about the afore-mentioned difference in behaviour?

[15:27:00.0000] <webben>
is evidence of that evidence that it would be an issue or not?

[15:27:01.0000] <Hixie>
my stats suggest <acronym> is used rarely enough that the blind would not lose out if the definitions for some of the acronyms on the web went from being treated like acronyms to being treated like arbitrary titles.

[15:28:00.0000] <Hixie>
note that i'm not saying it should be illegal to handle <acronym> like <abbr>

[15:28:01.0000] <Hixie>
just that it's not a big enough deal to warrant its own set of conformance criteria

[15:28:02.0000] <webben>
How do you quantify that?

[15:29:00.0000] <webben>
Hixie: Are you basically saying whether an element is worth describing depends on how common it is?

[15:30:00.0000] <Hixie>
it's certainly one of the considerations

[15:30:01.0000] <webben>
Well what are the other considerations that bear on <acronym>?

[15:31:00.0000] <Hixie>
i don't understand the question

[15:32:00.0000] <webben>
Oh. Hmm. You said frequency of current use is one of the considerations for whether an element is worth describing. So there must be additional considerations. I'm asking what those are.

[15:32:01.0000] <webben>
(talking here of elements that already exist)

[15:33:00.0000] <Hixie>
how it's used, how it's implemented, what happens to the content that uses it if the element is just ignored, etc

[15:33:01.0000] <Hixie>
everything that goes into language design

[15:33:02.0000] <webben>
Hixie: How far is abbr over-represented in the statistics thanks to abuse by microformats?

[15:33:03.0000] <Hixie>
that's another example of something to consider

[15:34:00.0000] <Hixie>
(in practice microformats is hardly on the radar)

[15:35:00.0000] <webben>
Hixie: Do your statistics attach any particular importance to quality of content and the importance of its accessibility?

[15:35:01.0000] <Hixie>
i can't really discuss the details, but that is something i am able to track to some extent, yes

[15:35:02.0000] <webben>
e.g. a qualitative study might (for argument's sake) find the acronym is well-used to introduce special acronyms in well-authored documents

[15:35:03.0000] <Hixie>
it might

[15:35:04.0000] <Hixie>
it might also find it's used for selling viagra

[15:36:00.0000] <Hixie>
who knows

[15:36:01.0000] <webben>
even though it's not used to mark up every acronym in the documents

[15:36:02.0000] <webben>
Hixie: My point is that frequency of use isn't particularly meaningful for the utility of preserving <acronym>

[15:36:03.0000] <Hixie>
i argue that it is

[15:36:04.0000] <webben>
since it's not necessarily an element one would expect to be used often

[15:37:00.0000] <Hixie>
however i don't argue it's the only measure

[15:37:01.0000] <Hixie>
one must take all aspects into account

[15:38:00.0000] <webben>
Hixie: How disproportionate is its usage to what one would expect its usage to be based on the HTML 4.01 specification?

[15:39:00.0000] <webben>
And without qualitative studies, how have the other aspects been taken into account?

[15:39:01.0000] <Hixie>
it's usage is about what one would expect

[15:40:00.0000] <Hixie>
to answer your second question, i have extensive experience with HTML, having worked for two separate browser vendors and worked with two others, and a number of other people in the community are very experienced as well. we bring our experience to bear on such matters, augmenting our experience with qualitative studies.

[15:41:00.0000] <webben>
Hixie: No I meant wrt to acronym specifically.

[15:41:01.0000] <webben>
There's been a lot of argumentation about whether one can replace acronym and abbr with just abbr.

[15:41:02.0000] <Hixie>
i forget, i mean we decided that three years ago

[15:41:03.0000] <Hixie>
god only knows what our reasoning was

[15:41:04.0000] <webben>
But that's quite different to just pretending one of them is a meaningless signifier.

[15:42:00.0000] <Hixie>
it's very clear (to me at least) that having more than one of these elements is dumb

[15:42:01.0000] <webben>
Hixie: Like I said, that's a completely different issue.

[15:42:02.0000] <Hixie>
we can kill both and add a new one, or reuse one of the existing ones (they have about the same usage).

[15:42:03.0000] <webben>
That's more like: do both <i> and <em> need to be conformant.

[15:42:04.0000] <Hixie>
killing both and adding a new one seems dumb

[15:43:00.0000] <Hixie>
so that leaves killing one and keeping one

[15:43:01.0000] <Hixie>
if we are to do that, it seems like we should keep the one with the more generic name

[15:43:02.0000] <Hixie>
that's pretty much all there is to it, as far as i can see

[15:43:03.0000] <webben>
Hixie: Yes ... I don't see why "killing one" involves pretending the other has no semantic.

[15:43:04.0000] <Hixie>
it doesn't have to

[15:43:05.0000] <webben>
exactly

[15:43:06.0000] <Hixie>
i already said that we could mention what <acronym> means in the ua-only part of the spec

[15:44:00.0000] <Hixie>
i don't think it'd make the slightest difference to the world one way or the other

[15:44:01.0000] <webben>
Hixie: Yes but then you said it should be treated as <span>.

[15:44:02.0000] <Hixie>
i think allowing it to be treated as span (and making that the minimum requirement) causes minimial harm

[15:45:00.0000] <webben>
Hixie: How does it cause /less/ harm than treating it as the new <abbr>, which can be used for marking up acronyms too?

[15:45:01.0000] <Hixie>
it doesn't cause less harm

[15:45:02.0000] <webben>
because it seems obvious that it in fact causes more harm

[15:45:03.0000] <webben>
even if the harm is small

[15:45:04.0000] <Hixie>
0.000001 harm units is minimal harm, even if it is more harm than 0.0000001 harm units.

[15:45:05.0000] <Hixie>
the total harm caused is not the only concern

[15:46:00.0000] <webben>
No. Minimal means least.

[15:46:01.0000] <Hixie>
no it doesn't

[15:46:02.0000] <Hixie>
but whatever. i think allowing it to be treated as span (and making that the minimum requirement) causes little harm.

[15:47:00.0000] <webben>
Hixie: Shouldn't it be an objective of the spec to cause "least harm"?

[15:47:01.0000] <Hixie>
no

[15:47:02.0000] <Hixie>
not to the exclusion of all else

[15:47:03.0000] <webben>
What's the counter-acting objective?

[15:47:04.0000] <webben>
(in this case)

[15:47:05.0000] <Hixie>
implementation simplicity in 50 years when no content using <acronym> exists any more

[15:47:06.0000] <Hixie>
implementation simplicity for non-TA user agents

[15:47:07.0000] <Hixie>
simplicity in the spec

[15:48:00.0000] <webben>
Hixie: non-TA user agents are precisely the agents that cannot afford such simplicity, since they are responsible for exposing content to ATS

[15:48:01.0000] <Hixie>
like i said, nothing *prevents* them from doing better than the minimum requirement

[15:48:02.0000] <webben>
effectively, there's not really any such thing as a non-AT user agent ... there's just user agents that break the usability conventions of the host OS

[15:49:00.0000] <webben>
(e.g. opera treats its current failure to work with windows AT as a bug; ditto webkit)

[15:50:00.0000] <kingryan>
 /away

[15:50:01.0000] <kingryan>
whoops

[15:50:02.0000] <webben>
Hixie: What makes you think people are going to convert existing content?

[15:51:00.0000] <webben>
rather than just archive it?

[15:51:01.0000] <Hixie>
webben: people aren't going to. but it will be overwhelmed by new content in time, to the point where <acronym> is rarely if ever met by users.

[15:51:02.0000] <Hixie>
anyway, gotta go. meeting.

[15:51:03.0000] <webben>
okay, thanks for talking about this :)

[15:51:04.0000] <webben>
have a good meeting


2007-06-16
[01:48:00.0000] <hsivonen>
Hixie: I'm getting personal feedback that disapproves of giving semantics to previously presentational elements like <small>. Do you have a PR story I could refer to?

[04:12:00.0000] <jgraham>
In pre/textarea blocks only the first newline gets dropped, right? 

[04:13:00.0000] <jgraham>
/me has discovered that some html5lib testcases drop more which seems like a bug

[04:13:01.0000] <jgraham>
or, I suppose I'm making a mistake...

[04:21:00.0000] <hsivonen>
Hixie: have you run a Google analysis on what percentage (permilliage?) of text/html pages have an <svg> or <math> tag in them?

[04:21:01.0000] <hsivonen>
Hixie: that is, would we break the Web if we fixed MathML in HTML and SVG in HTML?

[05:40:00.0000] <Jero>
sweet: http://digg.com/programming/HTML5_differences_from_HTML4

[05:41:00.0000] <Jero>
hopefully showing this document to a large audience as digg  will make people understand html5 better

[06:53:00.0000] <Dashiva>
Jero: From the comments there, it seems many people don't want to understand :)

[07:00:00.0000] <krijnh>
'I will never leave you center tag, my love :('

[07:00:01.0000] <krijnh>
Hehe

[07:01:00.0000] <Jero>
yeah, some comments are pretty humorous :p

[07:01:01.0000] <krijnh>
They aren't too bad

[07:03:00.0000] <Jero>
Dashiva: I suppose you're right but at least we make them think about it

[07:04:00.0000] <Jero>
and some critique is actually IMO not completely wrong

[07:05:00.0000] <annevk>
anything new?

[07:05:01.0000] <annevk>
besides the digg link above :)

[07:05:02.0000] <Philip`>
/me guesses that getting random patterns of colours (presumably picking up random sections of memory) in canvas drawing is not entirely optimal from a security point of view

[07:05:03.0000] <annevk>
guess the debate on XHTML is settled with that...

[07:05:04.0000] <annevk>
XHTML5*

[07:06:00.0000] <krijnh>
"XHTML is the future. I can't wait for XHTML2." - that's too bad then

[07:06:01.0000] <Jero>
i see a lot of people that are confused with the naming

[07:07:00.0000] <Jero>
"What is the XHTML 5.0? I've heard about HTML 5.0 and XHTML 2.0. Did the naming is changed?"

[07:07:01.0000] <annevk>
heh, they're promoting my blog

[07:07:02.0000] <krijnh>
Did Digg users undergo an upgrade or something?

[07:08:00.0000] <annevk>
yeah, the last time they looked at HTML5 it kind of sucked, now it rules

[07:08:01.0000] <krijnh>
Indeed

[07:08:02.0000] <Jero>
i think it got popular because Kevin Rose was one of the first to digg it

[07:09:00.0000] <Jero>
and many people have him as a friend, so that way it becomes instantly popular

[07:09:01.0000] <krijnh>
Yay for web2.0

[07:10:00.0000] <Jero>
"HTML 5...wouldn't that mean that Web 5.0 isn't far off?" wtf...

[07:10:01.0000] <annevk>
"HTML5 is so strict that it steps on my balls while wearing high heels"

[07:11:00.0000] <krijnh>
"He didn't say he didn't enjoy it."

[07:11:01.0000] <annevk>
Jero, we've been talking about Web 5.0 a lot here, actually

[07:11:02.0000] <Jero>
oh snap, i've been missing out

[07:11:03.0000] <krijnh>
XML5, HTTP5, WEB5, where does it end :)

[07:11:04.0000] <krijnh>
CSS5

[07:11:05.0000] <krijnh>
DOM5

[07:12:00.0000] <krijnh>
R5

[07:12:01.0000] <annevk>
SVG5

[07:12:02.0000] <Philip`>
Implemented in Firefox 5 and Safari 5? And, uh, Opera 15?

[07:12:03.0000] <krijnh>
Opera5 prolly already supported all of this anyway

[07:12:04.0000] <annevk>
Opera 2^5

[07:13:00.0000] <Philip`>
Opera X.5, maybe

[07:14:00.0000] <annevk>
I like to think I'm better informed :p

[07:14:01.0000] <krijnh>
Yeah, you have that habit ;)

[07:47:00.0000] <annevk>
jgraham, would be good if you could e-mail that yes

[07:48:00.0000] <annevk>
jgraham, either to the list or just to me

[07:48:01.0000] <jgraham>
annevk: You are referring to the HTML4/5 differences thing?

[07:49:00.0000] <annevk>
yeah

[07:50:00.0000] <annevk>
http://penguinpetes.com/b2evo/index.php?title=here_comes_html5_duck&more=1&c=1&tb=1&pb=1

[07:51:00.0000] <Dashiva>
It's sort of depressing to see people ask "Why add <header>, <aside>, <section>, etc when we have <div> already?"

[07:51:01.0000] <Dashiva>
And these are the people who claim they want semantic markup?

[07:53:00.0000] <annevk>
jgraham, I like your suggestions btw, I'll guess I'll look into them tomorrow or Monday or so

[07:54:00.0000] <annevk>
wow, there's lots of people who linked to that story overnight

[07:54:01.0000] <jgraham>
Dashiva: One of the suggestions I'm going to add to my list for Anne is to mention that nesting <section> alters heading depth like <h1>-<h6>

[07:55:00.0000] <annevk>
Yeah, we should probably group some of the new elements together that take part in a model

[07:55:01.0000] <annevk>
maybe also have a table at the end that has all the differences as a simple overview including links to the spec or something

[07:58:00.0000] <hsivonen>
are there cases when "insertion point" is not either undefined or just before the next input character?

[07:59:00.0000] <annevk>
/me isn't sure

[08:00:00.0000] <hsivonen>
annevk: does html5lib support document.write()?

[08:00:01.0000] <annevk>
in theory

[08:01:00.0000] <annevk>
we have a stream that you can inject into

[08:01:01.0000] <hsivonen>
ok. I wonder if I should implement tokenizer-level support for document.write()

[08:01:02.0000] <hsivonen>
if I do, it'll be asynchronous

[08:02:00.0000] <hsivonen>
so that the method will return immediately and the caller may listen to an event indicating when the buffer has been parsed

[08:02:01.0000] <hsivonen>
I'm not sure whether all this is worth the trouble, though

[08:03:00.0000] <annevk>
prolly not

[08:07:00.0000] <hsivonen>
it would be reasonably easy to push the current input buffer state on a stack if the insertion point is never weirder than "before the next input character"

[10:53:00.0000] <Jero>
I assume this is in the close tag open state? http://html5.org/tools/web-apps-tracker?from=900&to=901


2007-06-17
[18:44:00.0000] <Hixie>
hsivonen: i don't have a good page to point to that i can think of. what's the argument, exactly?

[18:44:01.0000] <Hixie>
hsivonen: haven't looked at the svg/mathml thing. i don't think putting svg in html would make sense, though, and presentational mathml is nearly as bad.

[18:47:00.0000] <Hixie>
hsivonen: and the insertion point can be weirder than that iirc

[20:32:00.0000] <othermaciej>
Sam Ruby puts SVG in XHTML

[01:33:00.0000] <met_>
http://therealcrisp.xs4all.nl/blog/2007/06/17/fixing-the-web-fix-your-browser/

[02:28:00.0000] <Hixie>
wow, molly sure is taking a beating

[03:29:00.0000] <annevk>
ooh, quirks mode

[03:35:00.0000] <Ducki>
:O

[03:36:00.0000] <annevk>
Hixie, did you leave out almost standards mode with some hope that we might change some CSS stuff to pull almost and standards mode back together?

[04:22:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0017.html "Furthermore XHTML2 maintains  

[04:22:01.0000] <annevk>
backwards compatibility with HTML4 and XHTML1 in a way that we do not. It has no clean slate policy, but instead tries to maintain elements and attributes from prior W3C recommendations."

[04:23:00.0000] <hasather_>
annevk: hehe, wtf

[05:15:00.0000] <annevk>
I think I've addressed most requests so far: file://localhost/home/annevk/projects/dev.w3.org/html5/html4-differences/Overview.html

[05:16:00.0000] <hasather_>
annevk: that was localhost

[05:17:00.0000] <annevk>
cool

[05:17:01.0000] <hasather_>
:)

[05:17:02.0000] <annevk>
It's also checked in though: http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html

[05:18:00.0000] <hsivonen>
Hixie: the rationale behind the semantic change complaint seemed to be that you are pulling the rug from under those who are authoring assuming previous de jure semantics

[05:19:00.0000] <hsivonen>
Hixie: The idea that SVG should be kept out of text/html because it is presentational is totally unconvincing. I don't see how things get any better--even theoretically--when you move a chunk of markup into an external network resource

[05:19:01.0000] <hsivonen>
Hixie: do you think my thesis, the Distler blog and Sam Ruby's blog would benefit from putting SVG into a separate HTTP resource?

[05:23:00.0000] <annevk>
"http://www.ibm.com/data/dtd/v11/ibmxhtml1-transitional.dtd"

[05:23:01.0000] <annevk>
heh

[05:40:00.0000] <kfish>
hi ctford 

[05:40:01.0000] <ctford>
hello all

[05:42:00.0000] <ctford>
does anyone know if the new <video> tag supports width and height attributes to force the browser to display it as a particular size?

[05:42:01.0000] <ctford>
i know there are videoWidth and videoHeight attributes, but they seem to refer to the native height of the video, not the size it's displayed at.

[05:42:02.0000] <annevk>
you size it with CSS and then the video scales to fit to the width and height

[05:43:00.0000] <annevk>
(videoHeight and videoWidth are DOM attributes, not content attributes)

[05:43:01.0000] <ctford>
yep, makes sense

[05:43:02.0000] <ctford>
so could you do <video src=??? width=200 height=200 /> then?

[05:44:00.0000] <annevk>
just <video src=video>

[05:44:01.0000] <annevk>
video { width:100%; height:100% } in your CSS

[05:45:00.0000] <kfish>
annevk, so to give the browser a hint about the actual video dimensions, we'd have to generate the corresponding CSS with px values?

[05:45:01.0000] <annevk>
there's no way to give hints

[05:46:00.0000] <annevk>
there's a way to specify a size for the video frame in which the video will render (CSS)

[05:46:01.0000] <annevk>
if you don't use CSS the video will be displayed with its native height and width

[05:47:00.0000] <kfish>
sure, except that it might take a few seconds to determine that

[05:47:01.0000] <kfish>
but specifying the size of the video frame is what i was referring to anyway

[05:47:02.0000] <annevk>
I suppose one could argue that the size of a video frame is not presentational

[05:47:03.0000] <annevk>
dunno

[05:48:00.0000] <annevk>
for now there are no such attributes though

[05:49:00.0000] <ctford>
annevk: so you can't use a style attribute?

[05:49:01.0000] <ctford>
i know it's better practice to put it in a separate css stylesheet

[05:51:00.0000] <kfish>
ctford, putting it into a style element would be ok (not require generating a separate css resource for each video)

[05:52:00.0000] <ctford>
kfish: for our purposes it's probably best to put all the sizing in css, because that's where you'd be messing with the page layout and it's the page layout that determines what size you want the videos to be.

[05:54:00.0000] <kfish>
yes, but if it's just width and height than that css can live inside <style> ... </style> in the page

[05:54:01.0000] <annevk>
ctford, style= is not allowed

[05:54:02.0000] <annevk>
<style> is

[05:54:03.0000] <ctford>
annevk: ah, thanks

[05:55:00.0000] <ctford>
kfish: sure, it could live in the page, but the rest of the sizing info is in separate stylesheets right?

[05:57:00.0000] <kfish>
ctford, for cmmlwiki, the rest of the styling is static across the site, not dependent on the video content

[05:59:00.0000] <ctford>
kfish: yeah, so don't we have to force the video to be a certain height so that it fits in with the static sizing of the rest of the page?

[05:59:01.0000] <kfish>
ctford, -> #annodex :-)

[06:00:00.0000] <ctford>
:)

[06:00:01.0000] <kfish>
annevk, thanks

[06:01:00.0000] <ctford>
cheers annevk

[06:03:00.0000] <annevk>
you guys working on some <video> project?

[06:04:00.0000] <kfish>
annevk, yeah, just putting support into cmmlwiki, eg. http://media.annodex.net/cmmlwiki/

[06:04:01.0000] <kfish>
which is a demo for annodex, which is about hyperlinked video

[06:04:02.0000] <kfish>
www.annodex.net :-)

[06:06:00.0000] <kfish>
we also work closely with xiph.org on ogg

[06:06:01.0000] <annevk>
cool

[06:17:00.0000] <annevk>
/me wonders how far Hixie is with parser feedback...

[06:17:01.0000] <annevk>
/me wonders if he mentioned that Opera is doing </br> and </p> quirks in either parsing mode already

[06:17:02.0000] <annevk>
/me ... lik IE

[06:36:00.0000] <zcorpan>
annevk: i did some testing on that before, can't remember if i have sent results to the list though

[06:37:00.0000] <zcorpan>
http://simon.html5.org/test/html/parsing/stray-end-tags/

[06:38:00.0000] <annevk>
yeah, we have <BR> and <P></P> for 001 now

[06:38:01.0000] <annevk>
identical results in 002 and 003

[06:39:00.0000] <annevk>
wow, IE does it for a lot more elements...

[06:39:01.0000] <zcorpan>
indeed

[06:39:02.0000] <zcorpan>
</plaintext>!

[06:39:03.0000] <annevk>
h1-h6, address, ol, ul, etc.

[06:40:00.0000] <Jero>
yeah, you should check the innerHTML in IE for test 110 on http://jero.net/lab/ph5p/tests.html

[06:40:01.0000] <annevk>
fancy

[06:41:00.0000] <annevk>
Firefox does it 1) only in quirks) and 2) only for BR and P

[06:42:00.0000] <annevk>
I like </plaintext>

[06:42:01.0000] <Jero>
Safari does <p></p> in standards mode

[06:43:00.0000] <annevk>
Does Safari do <br> too?

[06:43:01.0000] <zcorpan>
Jero: are tests 50 and 83 up to date? (the spec changed recently)

[06:43:02.0000] <Jero>
only in 003

[06:43:03.0000] <annevk>
k

[06:43:04.0000] <annevk>
guess we'll get </br> and </p> in all modes at least

[06:43:05.0000] <kfish>
if anyone has a browser supporting <video>, try eg: http://media.annodex.net/cmmlwiki/SFD2005-Trailer

[06:44:00.0000] <Jero>
zcorpan: what changes are you referring to?

[06:44:01.0000] <Jero>
i got these tests from html5lib

[06:44:02.0000] <annevk>
Some tests in html5lib are now wrong

[06:44:03.0000] <annevk>
And some might contradict tests5.dat

[06:45:00.0000] <Jero>
these are only the tests from tests1.dat

[06:45:01.0000] <annevk>
those contain some errors now

[06:45:02.0000] <Jero>
do you know which tests (except 50 and 83)?

[06:46:00.0000] <annevk>
no, I haven't looked through that yet

[06:46:01.0000] <annevk>
I'm actually hoping someone else will update stuff...

[06:47:00.0000] <Jero>
also, what changes to the spec made the tests have errors?

[06:47:01.0000] <annevk>
the handling of <!-- and --> in <style>, <script>, etc.

[06:48:00.0000] <zcorpan>
Jero: http://html5.org/tools/web-apps-tracker?from=885&to=886

[06:48:01.0000] <annevk>
the handling of "<" in tag / attribute names, attribute values

[06:48:02.0000] <Jero>
i've fixed the < in tags yesterday in my script

[06:48:03.0000] <Jero>
but not the handling of <!--

[06:49:00.0000] <zcorpan>
"<" is http://html5.org/tools/web-apps-tracker?from=899&to=902

[06:50:00.0000] <Jero>
yup, i had seen those

[06:50:01.0000] <Jero>
*have

[06:51:00.0000] <annevk>
<!-- checking seems annoying

[06:51:01.0000] <annevk>
< is trivial

[06:51:02.0000] <annevk>
extended DOCTYPE parsing seems doable, but the big table makes it cumbersome

[06:52:00.0000] <annevk>
(for quirks mode checking)

[06:53:00.0000] <annevk>
one of the problems I have is that I don't have all the dependencies for html5lib anymore on my new machine so running the tests doesn't work...

[07:08:00.0000] <hsivonen>
<style> compared to width= height= is awfully impractical

[07:09:00.0000] <hsivonen>
/me doesn't mind having presentational stuff when it's practical

[07:11:00.0000] <zcorpan>
hsivonen: for <img>?

[07:12:00.0000] <Philip`>
<div><style scoped>video { width: 300px; height: 150px }</style><video ...>...</video></div> still seems quite verbose (and non-backward-compatible)

[07:13:00.0000] <hsivonen>
zcorpan: video

[07:13:01.0000] <zcorpan>
ok

[07:13:02.0000] <Philip`>
/me guesses that <video ...><style scoped>video { width: 300px; height: 150px }</style></video> wouldn't work because the contents of <video> get ignored, but isn't sure what says that is true

[07:14:00.0000] <zcorpan>
Philip`: contents of video is still processed

[07:14:01.0000] <Philip`>
Oh, maybe it's not true

[07:14:02.0000] <Philip`>
"User agents should not show this fallback content to the user." - sounds like it's there but undisplayed

[07:14:03.0000] <Philip`>
in which case you could style videos in that way

[07:14:04.0000] <zcorpan>
if style scoped will affect the parent

[07:15:00.0000] <Jero>
is the scope attribute new?

[07:15:01.0000] <Jero>
*scoped

[07:15:02.0000] <zcorpan>
Jero: yes

[07:15:03.0000] <Philip`>
Oh, it does at the moment but I guess that could change

[07:16:00.0000] <zcorpan>
hm, wonder if it should be disallowed to put <style scoped> in head

[07:17:00.0000] <Jero>
yeah, that would seem like a good idea

[07:17:01.0000] <zcorpan>
and/or whether such elements should just affect the whole document anyway

[07:17:02.0000] <Jero>
i think the attribute should just be ignored

[07:17:03.0000] <zcorpan>
not sure

[07:17:04.0000] <zcorpan>
it makes implementation more complex

[07:19:00.0000] <Jero>
i doubt that

[07:19:01.0000] <Jero>
you could easily check whether or not the style element is in the head element

[07:19:02.0000] <Jero>
if so, ignore the scoped attribute

[07:19:03.0000] <zcorpan>
the alternative is to not check

[07:22:00.0000] <Jero>
and let it be ignored you mean?

[07:25:00.0000] <zcorpan>
apply to the head

[07:45:00.0000] <Jero>
zcorpan: that's almost the same :p

[07:46:00.0000] <Jero>
though, as the purist that I am, I'm still not sure if this is such a good idea

[07:47:00.0000] <Jero>
i understand the advantages of course, but I think having a more powerful styling language (CSS5) would be much better

[08:04:00.0000] <Lachy>
not surprisingly, unicode case folding has not been implemented properly by browsers :-(

[08:16:00.0000] <Jero>
In the U+002D HYPHEN-MINUS (-) case of the data state ( http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tokenisation.html#data-state ), why check if there are at least three character before the current character in the input stream?

[08:16:01.0000] <Jero>
oh nvm

[08:17:00.0000] <Jero>
i get it now

[08:53:00.0000] <Jero>
zcorpan: I've implemented revision 886, thanks

[08:54:00.0000] <zcorpan>
Jero: if <style scoped> in head is non-conforming, the handling of it can be considered error handling. why make it more complex than it needs to be? it's not like there is content that depends on a particular handling

[08:54:01.0000] <zcorpan>
Jero: cool

[08:55:00.0000] <Jero>
zcorpan: true

[10:48:00.0000] <Lachy>
/me fixed several more issues in Selectors API http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=UTF-8

[11:39:00.0000] <Jero>
oh snap, i had been working for a couple hours on a bug that i thought was in my implementation of the adoption agency algorithm

[11:40:00.0000] <Jero>
but it turned out that i forgot to change the first character of closing tags from upper to lower case... </frustrations>

[12:04:00.0000] <Jero>
With "<p><b></p>" a </b> is generated. Should this B element remain in the list of active formatting elements?

[12:06:00.0000] <Hixie>
annevk: i left out almost standards mode because as far as html5 is concerned, there's no such thing

[12:07:00.0000] <Hixie>
hsivonen: re changing semantics -- we're not actually changing them, though. <i> and <small> are just broadened to cover non-visual cases, really.

[12:08:00.0000] <Hixie>
hsivonen: having SVG in an external resource emphasises the point that the resource is not part of the content, and makes it at least slightly more likely that an alternative aural presentation is given (e.g.).

[12:08:01.0000] <Hixie>
hsivonen: and if it's purely presentational, and thus would not have a visual equivalent, then it should be in hte stylesheet where it can be switched out

[12:11:00.0000] <Hixie>
Jero: unless the spec says to take it out, it stays in

[12:13:00.0000] <Jero>
ok, thanks

[13:08:00.0000] <zcorpan>
"[ ] Notify me of followup comments via e-mail" -- wow, all blogs should have this feature (from http://dev.aizatto.com/2007/06/18/taking-a-peek-at-html-5/ )

[13:12:00.0000] <met_>
http://www.andybudd.com/archives/2007/06/whither_w3c/

[13:15:00.0000] <Jero>
zcorpan: most WP blogs have a separate feed just for the comments 

[13:24:00.0000] <zcorpan>
Jero: true

[13:24:01.0000] <jruderman>
but then you have to add the feed manually, and remove it after a few weeks to avoid cluttering up your feed reader

[13:25:00.0000] <jruderman>
and you have to use a feed reader (i don't)

[13:26:00.0000] <zcorpan>
indeed, adding and removing feeds for all blogs you comment on is cumbersome. getting email is less so

[13:26:01.0000] <zcorpan>
s/blogs/blog posts/

[13:31:00.0000] <jgraham>
Hmm, it seems like a river-of-news style feedreader would work better for comment feeds since you wouldn't have old posts cluttering up the UI most of the time (though they'd still get checked I suppose)

[13:32:00.0000] <jruderman>
river-of-news?

[13:32:01.0000] <jgraham>
like planet or venus

[13:32:02.0000] <jruderman>
ahh

[14:11:00.0000] <hsivonen>
Hixie: Re: changing semantics: I think the issue has been raised often enough that we need a FAQ entry

[14:13:00.0000] <hsivonen>
Hixie: I still entirely unconvinced about the practicality of your and annevk's stance regarding SVG in text/html. From my point of view, it is a feature parity bug between HTML5 and XHTML5 regardless of whether it's presentational

[14:13:01.0000] <hsivonen>
s/I/I'm/

[14:14:00.0000] <jruderman>
SVG in text/html!?

[14:15:00.0000] <hsivonen>
jruderman: yes. defining appropriate namespace assignment in the tree builder and a void element mode flag in the tokenizer

[14:17:00.0000] <hsivonen>
jruderman: I think publications like the Distler blog should be able to use text/html with math and vector graphics ending up in the right namespaces in the DOM

[14:18:00.0000] <jruderman>
what would the syntax look like?

[14:18:01.0000] <hsivonen>
<svg> ... </svg> and <math> .... </math>

[14:19:00.0000] <hsivonen>
jruderman: implicit namespace assignment based on <svg> and <math> subtree root

[14:19:01.0000] <jruderman>
what about foreignObject?

[14:20:00.0000] <jruderman>
or using an html:img as the denominator of a fraction?

[14:20:01.0000] <jruderman>
would those still require moving to xhtml?

[14:20:02.0000] <hsivonen>
jruderman: I guess having an <html> subtree in there should switch back to the XHTML namespace

[14:20:03.0000] <jruderman>
hmm

[14:22:00.0000] <Philip`>
Could it be done so that future extensions (like adding <x3d>...</x3d> or whatever) can degrade gracefully, rather than being treated like a collection of <span>s and text that will get misinterpreted by old UAs (and confuse search engines, etc)?

[14:23:00.0000] <hsivonen>
Philip`: I don't know how to handle arbitrary vocabulary combinations without prefixing

[14:23:01.0000] <hsivonen>
Philip`: but I want to optimize for SVG and MathML

[14:23:02.0000] <hsivonen>
Philip`: I'd be OK with a hairier arrangement for arbitrary vocabularies if we really want to do those

[14:23:03.0000] <hsivonen>
Philip`: (I know that there are WG participants who want to)

[14:24:00.0000] <Philip`>
Hmm, maybe something like <svg xmlns>...</xml> so it's easy to remember/write but means browsers can easily determine that it's some XML extension and they should ignore it unless they understand what "svg" means?

[14:24:01.0000] <Philip`>
Uh

[14:24:02.0000] <Philip`>
<svg xmlns>...</svg>

[14:25:00.0000] <hsivonen>
Philip`: radical!

[14:33:00.0000] <Jero>
erm... SVG and MathML in HTML?

[14:33:01.0000] <Jero>
we might as well kill XML then...

[16:16:00.0000] <weinigLap>
Hixie: you around?

[16:17:00.0000] <weinigLap>
Hixie: I am a little confused about the Location object in the HTML5 spec

[16:17:01.0000] <weinigLap>
Hixie: are the attributes supposed to readonly?

[16:27:00.0000] <Dashiva>
weinigLap: They aren't actually readonly, as setting them maps to the assign() method

[16:28:00.0000] <weinigLap>
/me nods

[16:28:01.0000] <weinigLap>
hence my confusion

[16:29:00.0000] <weinigLap>
Dashiva: do you know why they are labeled readonly in the interface definition?

[16:29:01.0000] <Dashiva>
The attributes are read-only

[16:29:02.0000] <Dashiva>
You can't change them. However, setting them is treated as an implicit call to change the current location

[16:30:00.0000] <weinigLap>
ah

[16:30:01.0000] <weinigLap>
weird

[16:30:02.0000] <weinigLap>
thanks though

[16:51:00.0000] <Hixie>
weinigLap: i don't think they should be readonly... send mail?

[16:52:00.0000] <weinigLap>
Hixie: pardon?

[16:52:01.0000] <weinigLap>
oh, send you an email, my bad

[16:52:02.0000] <Hixie>
sorry, yeah, i meant send mail to whatwg⊙wo to report the error :-)

[16:52:03.0000] <Hixie>
hsivonen: yt?

[16:53:00.0000] <weinigLap>
Hixie: doing it now, thanks

[16:54:00.0000] <Hixie>
np

[16:54:01.0000] <Hixie>
thanks you!


2007-06-18
[18:46:00.0000] <mpt>
/me wonders if <image/svg>, <application/mathml+xml>, etc would work

[18:51:00.0000] <othermaciej>
would work in what?

[19:04:00.0000] <mpt>
HTML

[19:05:00.0000] <mpt>
instead of having the HTML specification containing yet another registry for document types

[19:14:00.0000] <othermaciej>
you intend those to be tag names?

[19:15:00.0000] <othermaciej>
I don't think that generalizes, some interesting XML languages don't have a specific MIME type assigned

[21:20:00.0000] <Wolfman2000>
Evening.  Is there a link that shows what is planning to be deprecated in HTML5?

[21:52:00.0000] <mpt>
Wolfman2000, http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html#dropped-elements

[21:53:00.0000] <Wolfman2000>
this helps: thanks

[23:38:00.0000] <annevk>
yeah, XBL doesn't have a MIME type

[00:05:00.0000] <hsivonen>
Hixie: I'm awake now.

[00:28:00.0000] <annevk>
hsivonen, why is < more special than & or " or '?

[00:29:00.0000] <annevk>
they're all non-conforming in the end

[00:30:00.0000] <annevk>
jgraham, you around?

[00:39:00.0000] <hsivonen>
annevk: for unquoted attributes, no, they aren't all non-conforming in the end

[00:41:00.0000] <annevk>
attribute values?

[00:41:01.0000] <annevk>
oh, yeah

[00:41:02.0000] <hsivonen>
annevk: < is special, because it makes it look like a new tag is starting. but one isn't

[00:41:03.0000] <hsivonen>
annevk: so conformance checkers should be able to flag it for authors who are going WTF

[00:41:04.0000] <annevk>
title=2<5

[00:41:05.0000] <annevk>
there's a use case :)

[00:41:06.0000] <hsivonen>
annevk: also, it should be non-conforming to keep conforming docs reasonable safe for shipped Gecko and WebKit

[00:41:07.0000] <annevk>
<a title=2<5> already works in Firefox

[00:41:08.0000] <hsivonen>
oh

[00:41:09.0000] <annevk>
I think "<" is only special cased in some other states in at least Firefox

[00:42:00.0000] <hsivonen>
<a <title=2> doesn't

[00:42:01.0000] <hsivonen>
annevk: good point

[00:43:00.0000] <hsivonen>
anyway, I added warnings while I was at it in case Hixie disagrees about making it an error

[00:44:00.0000] <annevk>
I don't think it should be more than an error than a Unicode character that looks like "a" or something

[00:45:00.0000] <hsivonen>
I wonder how often Russians enter lookalikes by accident

[00:47:00.0000] <hsivonen>
but yeah, I wasn't properly thinking about some of those cases getting caught on a higher layer

[00:48:00.0000] <annevk>
I'm going to squash that bug in html5lib now I think

[00:49:00.0000] <annevk>
And fix all the tests...

[00:49:01.0000] <karlUshi>
<a title=q<p>math proposal</a>

[00:49:02.0000] <hsivonen>
annevk: please considering applying my patches for the tests before making other changes that prevent the patches from applying

[00:51:00.0000] <annevk>
at some point we should sort out math and ruby

[00:51:01.0000] <annevk>
hsivonen, can't you commit them yourself?

[00:51:02.0000] <hsivonen>
annevk: AFAIK, no

[00:52:00.0000] <karlUshi>
<a title=/b</a>math proposal</a>

[00:55:00.0000] <annevk>
indeed you can't

[00:55:01.0000] <Hixie>
hsivonen: you sent a mail about EOF having been dropped recently at some point from some sections in the tokeniser

[00:55:02.0000] <Hixie>
hsivonen: did you see if they actually got dropped? i think i may just never have had them!

[00:57:00.0000] <hsivonen>
Hixie: diff tells me you had them and dropped them

[00:59:00.0000] <Hixie>
huh

[00:59:01.0000] <Hixie>
any idea when?

[01:00:00.0000] <Hixie>
i'd love to bring them back exactly as they were

[01:00:01.0000] <Hixie>
totally wasn't my intention to drop them

[01:00:02.0000] <hsivonen>
Hixie: had them on June 12. not anymore on June 17

[01:00:03.0000] <Hixie>
ok, cool, thanks

[01:00:04.0000] <Hixie>
that'll help

[01:00:05.0000] <hsivonen>
Hixie: probably part of rev 886

[01:00:06.0000] <Hixie>
the reason i was looking for you earlier was to ask you what the use case for embedded svg was

[01:00:07.0000] <annevk>
maybe EOF and < were handled in the same way...

[01:00:08.0000] <hsivonen>
(rev # from off the top of my head)

[01:01:00.0000] <hsivonen>
annevk: they were

[01:01:01.0000] <Hixie>
EOF isn't in the diff for 866

[01:01:02.0000] <Hixie>
er, 886

[01:03:00.0000] <hsivonen>
Hixie: the use case is including diagrams or graphs

[01:03:01.0000] <Hixie>
aha

[01:03:02.0000] <hsivonen>
Hixie: with application/xhtml+xml you can include them inline

[01:03:03.0000] <Hixie>
899

[01:04:00.0000] <hsivonen>
Hixie: oh. sorry. I was thinking of another recent rev

[01:04:01.0000] <Wolfman2000>
Hixie: sounds like you know a lot about this HTML 5.  Do you have any idea when it will eventually take over HTML 4?

[01:04:02.0000] <hsivonen>
Hixie: so not being able to include them inline in text/html is a feature parity bug between the serializations

[01:04:03.0000] <Hixie>
Wolfman2000: i wrote html5 :-) how do hyou mean, take over?

[01:05:00.0000] <Wolfman2000>
There are some people in other channels that are worried of the progress of HTML 5.  They wonder when/if HTML 5 will become recommended over HTML 4.01 Strict.

[01:05:01.0000] <hsivonen>
Hixie: the fact that Jacques Distler, Sam Ruby and I intuitively want to include them inline when possible suggests that it is something that we think there's a point

[01:05:02.0000] <Hixie>
Wolfman2000: it won't be finished for many years

[01:06:00.0000] <othermaciej>
including XBL inline in HTML is surely useful

[01:06:01.0000] <Hixie>
Wolfman2000: then again, html4 isn't really finished yet either

[01:06:02.0000] <othermaciej>
and including SVG in inline XBL bindings for HTML is surely useful

[01:06:03.0000] <Wolfman2000>
Also, I have a demonstration page about a potentially valid use for target="_top".  Let me get it up on the server.

[01:06:04.0000] <Hixie>
Wolfman2000: so...

[01:06:05.0000] <Wolfman2000>
Hixie: ...html4 isn't?

[01:06:06.0000] <hsivonen>
Hixie: if the diagram or graph is not shared between multiple docs and isn't binary, there's really no good reason not to if putting it inline is possible

[01:06:07.0000] <Hixie>
Wolfman2000: it's full of bugs and errors (e.g. it says that media=screen is the default, not media=all)

[01:06:08.0000] <hsivonen>
s/is possible/if possible/

[01:07:00.0000] <hsivonen>
s/if putting/put/

[01:07:01.0000] <hsivonen>
/me hasn't properly woken up yet

[01:08:00.0000] <annevk>
Wolfman2000, contrary to other implementations, HTML5 is driven by implementation

[01:08:01.0000] <Wolfman2000>
Anyway, the page I mentioned: http://courses.ncsu.edu/csc234/lec/651/jaf_index.html  This page won't stay up forever: it's a design that has become retired due to lack of proper disabled support.

[01:08:02.0000] <Hixie>
hsivonen: should we also allow XBM inline? (just asking to find out where you think the boundary lies)

[01:08:03.0000] <annevk>
Wolfman2000, so when the spec is done, it will be properly implemented

[01:08:04.0000] <annevk>
Hixie, what's XBM?

[01:08:05.0000] <hsivonen>
Hixie: I don't know what XBM is

[01:08:06.0000] <Lachy>
did  you mean XBL?

[01:09:00.0000] <Hixie>
Wolfman2000: can you send your suggestion / help to me by e-mail? ian⊙hc (or whatwg⊙wo if you are subscribed)

[01:09:01.0000] <Wolfman2000>
I'm not subscribed yet.

[01:09:02.0000] <Hixie>
hsivonen: a text bitmap format

[01:09:03.0000] <Wolfman2000>
What's the best way to subscribe?

[01:09:04.0000] <Hixie>
hsivonen: i would have said PNG but that's not a text format

[01:09:05.0000] <Hixie>
Wolfman2000: http://whatwg.org/mailing-list

[01:10:00.0000] <hsivonen>
Hixie: but in general I'd be ok with being able to include any namespaced stuff with prefixes and optimize SVG and MathML to work without prefixes

[01:10:01.0000] <karlUshi>
monchrome bitmap

[01:10:02.0000] <Hixie>
hsivonen: hm interesting

[01:10:03.0000] <othermaciej>
XBM is not an XML language

[01:10:04.0000] <hsivonen>
Hixie: I guess we shouldn't do XBM because it wouldn't work by just hacking the parser

[01:10:05.0000] <othermaciej>
or indeed a markup language

[01:10:06.0000] <othermaciej>
you could put it in a data: URL I guess

[01:11:00.0000] <Wolfman2000>
awaiting confirmation email

[01:11:01.0000] <karlUshi>
http://en.wikipedia.org/wiki/XBM

[01:11:02.0000] <hsivonen>
Hixie: but putting SVG or MathML in the DOM already works, so fixing the parser is relatively low-hanging fruit compared to generalizing to XBM

[01:11:03.0000] <Hixie>
hsivonen: well fwiw i personally think it'd be great to have a math format and a vector graphics format in html. i think it would be a huge amount of work, though, and i think it would be highly controversial (so i don't plan on doing it anytime soon)

[01:11:04.0000] <Wolfman2000>
...on confirming the subscription request, can I use my preferred internet name instead of my real name?

[01:11:05.0000] <Hixie>
Wolfman2000: yes

[01:12:00.0000] <Wolfman2000>
Then consider me subscribed.

[01:12:01.0000] <hsivonen>
Hixie: well, pushing text/html and *not* being able to include arbitrary namespaces is also controversial to some

[01:13:00.0000] <hsivonen>
Hixie: and I'd expect SVG in text/html to have all the same warts as SVG in application/xhtml+xml

[01:14:00.0000] <Wolfman2000>
...so now that I'm in, all I do is send email to whatwg⊙wo and everyone sees it, right?

[01:14:01.0000] <Hixie>
hsivonen: i think general svg-like or mathml-like syntax in html has reasonably straightforward ways of being done (far from easy, but at least not technically difficult)

[01:14:02.0000] <Wolfman2000>
/me hasn't done this in awhile.

[01:14:03.0000] <hsivonen>
Hixie: so fixing SVG to WHATWG quality is a more general problem than enabling it in parsing

[01:14:04.0000] <Hixie>
hsivonen: i think a general-purpose namespaces system would be practically infeasible though in text/html

[01:14:05.0000] <Hixie>
Wolfman2000: yup

[01:15:00.0000] <hsivonen>
Hixie: would it be infeasible to hard-wire prefixes known to date and allowing the declaration of unknown prefixes?

[01:15:01.0000] <Hixie>
hsivonen: i'm not including svg 1.1 in html5 unchanged (e.g. requiring xlink namespace prefixes), that would just be missing a massive opporunity

[01:15:02.0000] <Hixie>
opportunity

[01:15:03.0000] <hsivonen>
(I am aware that the list of known prefixes to date is long)

[01:16:00.0000] <Hixie>
hsivonen: it couldn't be done just by using prefixes, that would have all kinds of issues (e.g. prefixes already do weird things in IE)

[01:16:01.0000] <hsivonen>
Hixie: more weird than what the obvious prefix bindings would do?

[01:16:02.0000] <Hixie>
hsivonen: i don't really have any interest in a simplistic solution that just shoehorns XML syntax into text/html to be honest

[01:17:00.0000] <Hixie>
hsivonen: i don't see the advantage and the costs can be great

[01:17:01.0000] <hsivonen>
Hixie: yeah, a general-purpose system would be more about fulfilling a bullet point 

[01:17:02.0000] <Hixie>
hsivonen: but anyway, this is something that's on the cards already

[01:18:00.0000] <hsivonen>
Hixie: but special-casing SVG and MathML still has a point, I think

[01:18:01.0000] <hsivonen>
Hixie: ok

[01:20:00.0000] <Wolfman2000>
Email has been sent, webpage link included.

[01:35:00.0000] <Wolfman2000>
...great.  I just received an email saying my email to the group got...well, bounced.  It's awaiting moderator approval.

[01:35:01.0000] <Wolfman2000>
/me thought he just signed up.

[01:35:02.0000] <annevk>
did you e-mail to the list you signed up for?

[01:35:03.0000] <annevk>
there are four lists

[01:37:00.0000] <Wolfman2000>
I thought I signed up to the right list.  I then emailed whatwg⊙wo

[01:37:01.0000] <Wolfman2000>
...oh crap.  I signed up for Implementors.

[01:38:00.0000] <Wolfman2000>
so I emailed it to the wrong spot?

[01:38:01.0000] <Hixie>
Wolfman2000: if it got stuck in the moderator queue you'll have to resubscribe, sorry :-|

[01:38:02.0000] <Wolfman2000>
...wha?!?

[01:39:00.0000] <Wolfman2000>
one shot and that's it?

[01:40:00.0000] <Wolfman2000>
...strange.  it still looks like I'm subscribed.  At least...in Implementors.

[01:40:01.0000] <annevk>
yeah, you have to subscribe to the other list

[01:40:02.0000] <Hixie>
Wolfman2000: no i mean you'll have to subcribe to the other list

[01:40:03.0000] <annevk>
and then e-mail your message again

[01:40:04.0000] <Hixie>
Wolfman2000: the moderator queue is just a black hole

[01:40:05.0000] <Hixie>
(we were getting too much spam for me to keep up)

[01:41:00.0000] <Wolfman2000>
From this page: http://www.whatwg.org/mailing-list   I ended up subscribing to Implementors

[01:41:01.0000] <Wolfman2000>
I assume there is a different page I'm supposed to go to then?

[01:41:02.0000] <annevk>
use http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org

[01:41:03.0000] <annevk>
(it's linked from that same page)

[01:42:00.0000] <Wolfman2000>
...oy.  four of them.

[01:42:01.0000] <Wolfman2000>
I'm assuming I should subscribe to all of them then?

[01:42:02.0000] <annevk>
no

[01:42:03.0000] <annevk>
just the ones you're interested in

[01:43:00.0000] <annevk>
I suggest you read the page briefly first

[01:43:01.0000] <Wolfman2000>
Probably a good idea.

[01:46:00.0000] <Wolfman2000>
alright, covered.  In the end...I think what I wanted the most was help-whatwg.org instead of whatwg.org

[01:46:01.0000] <Wolfman2000>
about to re-send the email

[01:47:00.0000] <Hixie>
hsivonen: fixed the EOF isue

[01:47:01.0000] <jgraham>
annevk: I'm here now...

[01:47:02.0000] <Hixie>
issue

[01:48:00.0000] <Wolfman2000>
...alright, chose to resend to the same place.  Let's hope it doesn't go to the black hole this time

[01:49:00.0000] <hsivonen>
Hixie: thakns

[01:51:00.0000] <annevk>
jgraham, it's already working

[01:51:01.0000] <annevk>
jgraham, I didn't have chardet but that seems to be optional now

[01:51:02.0000] <jgraham>
Great :)

[01:52:00.0000] <jgraham>
Less difficult questions early in the morning == good

[01:52:01.0000] <annevk>
Currently fixing the new entity stuff by making a small dirty hack that scrapes the HTML5 spec

[01:52:02.0000] <jgraham>
s/Less/Fewer

[01:52:03.0000] <annevk>
well, the multpage version

[01:55:00.0000] <hsivonen>
Safari appears not to have a chardet equivalent. does this mean that chardet is no longer needed on the real Web?

[01:56:00.0000] <hsivonen>
Opera seems to have autodetection available but it is scoped to Cyrillic, Chinese, Japanese or Korean at a time

[01:56:01.0000] <hsivonen>
what does IE7 do?

[01:57:00.0000] <Wolfman2000>
hsivonen: charset detection?  Hmm...hang on a second, while I test a certain webpage.

[01:57:01.0000] <hsivonen>
Wolfman2000: yes

[01:57:02.0000] <Wolfman2000>
...I think it's still needed.

[01:57:03.0000] <Wolfman2000>
http://foonmix.nothing.sh/  Use Shift_JIS

[01:58:00.0000] <Wolfman2000>
I believe my options are set to use utf-8 by default

[01:58:01.0000] <Wolfman2000>
does that help a bit hsivonen, or did I misunderstand?

[02:00:00.0000] <hsivonen>
Wolfman2000: does IE7 have an autodetector? 

[02:00:01.0000] <Wolfman2000>
hsivonen: I'm unsure: I'm on a Mac.

[02:00:02.0000] <Wolfman2000>
I was testing Safari

[02:00:03.0000] <hsivonen>
what do Japanese Safari users do? do they use another browser or switch encodings manually?

[02:00:04.0000] <Wolfman2000>
I needed to switch my encoding manually.

[02:00:05.0000] <Wolfman2000>
But I'm an American Safari user, so...I don't know.

[02:00:06.0000] <Wolfman2000>
Most Japanese people use Windows and IE. :(

[02:01:00.0000] <hsivonen>
well, hooking up jchardet to my tokenizer is on my todo list

[02:01:01.0000] <hsivonen>
I'd like to know, though, if passing only the first 512 bytes to chardet is enough

[02:02:00.0000] <Wolfman2000>
I don't know how to test that.  I've only just signed up, and I'm merely a simple TA/web designer

[02:22:00.0000] <zcorpan>
/me is at the opera office in linköping

[02:24:00.0000] <annevk>
simonp

[02:24:01.0000] <annevk>
:)

[02:25:00.0000] <zcorpan>
@opera.com?

[02:25:01.0000] <annevk>
yeah

[02:25:02.0000] <zcorpan>
oh yep. didn't know i had an opera email already

[02:28:00.0000] <hsivonen>
Hixie: why did you remove "Otherwise, if the next character is a U+003B SEMICOLON, consume that too. If it isn't, there is a parse error.

[02:28:01.0000] <hsivonen>
"

[02:28:02.0000] <hsivonen>
Hixie: in entity tokenization

[02:29:00.0000] <annevk>
because it is part of the entity name

[02:29:01.0000] <hsivonen>
whoa

[02:29:02.0000] <hsivonen>
/me is only diffing the tokenization section

[02:30:00.0000] <annevk>
I thought this entity stuff would be trivial to implement but it's not

[02:30:01.0000] <annevk>
I think <object>, <video> etc. should allow block-level fallback...

[02:30:02.0000] <hsivonen>
annevk: It took me a while to get the previous entity parsing right with minimal string object creation

[02:30:03.0000] <annevk>
The new entity stuff isn't stable either

[02:31:00.0000] <annevk>
Apparently IE does something different from this for attributes

[02:31:01.0000] <annevk>
So maybe you should not fix that for now

[02:31:02.0000] <hsivonen>
yeah

[02:31:03.0000] <hsivonen>
actually, I did it without string object creation at all

[02:33:00.0000] <annevk>
Hixie, it would be useful for other standards if HTML5 defined Almost Standards Mode for them

[02:33:01.0000] <annevk>
Hixie, if we're going to keep it, that is

[02:45:00.0000] <annevk>
hsivonen, fixed the tests

[02:47:00.0000] <hsivonen>
annevk: thanks

[02:48:00.0000] <hsivonen>
Hixie: I'd like to make entity names without the terminating semicolon parse errors to help conformance checkers alleviate author confusion is the face of typos

[02:48:01.0000] <zcorpan>
/me agrees with hsivonen

[02:49:00.0000] <annevk>
blah &amp blah

[02:50:00.0000] <annevk>
zcorpan, have you changed your entity script to work for attribute values already?

[02:50:01.0000] <zcorpan>
annevk: no

[02:50:02.0000] <zcorpan>
i can do it though

[02:50:03.0000] <annevk>
might be useful to see what IE does there (and how it compares to normal entity parsing)

[02:50:04.0000] <annevk>
cool

[02:50:05.0000] <hsivonen>
annevk: if IE is even remotely sane, the entity handling differences for attributes can be handled by loading a different entity table

[02:50:06.0000] <hsivonen>
/me hasn't tested

[02:51:00.0000] <zcorpan>
hopefully it just is the same table without the entries that don't end with ;

[02:52:00.0000] <annevk>
hsivonen, wouldn't that always be possible?

[02:53:00.0000] <hsivonen>
Hixie: btw, for easy scraping it would be nice to have the entity table lexicographically sorted

[02:53:01.0000] <hsivonen>
Hixie: just mentioning this in case you edit it anyway

[02:53:02.0000] <annevk>
hsivonen, there's a table scraping script

[02:53:03.0000] <hsivonen>
annevk: I haven't considered insane options :-)

[02:53:04.0000] <annevk>
it's really easy

[02:53:05.0000] <hsivonen>
annevk: pointer?

[02:54:00.0000] <annevk>
http://html5lib.googlecode.com/svn/trunk/python/utils/extract-entities.py

[02:54:01.0000] <hsivonen>
annevk: thanks

[02:54:02.0000] <hsivonen>
annevk: I guess I'll add lex sort to the script

[02:54:03.0000] <annevk>
just wrote that for my own usage, but integrating the new entity handling didn't work out to well

[02:54:04.0000] <annevk>
hsivonen, can I add you to the html5lib project?

[02:55:00.0000] <annevk>
so you can simply commit those changes yourself

[02:55:01.0000] <hsivonen>
annevk: sure

[02:55:02.0000] <annevk>
you have a google account?

[02:55:03.0000] <hsivonen>
hsivonen⊙gc

[02:56:00.0000] <annevk>
done

[02:56:01.0000] <hsivonen>
thanks

[02:56:02.0000] <annevk>
http://code.google.com/u/hsivonen/

[03:13:00.0000] <zcorpan_>
http://simon.html5.org/test/html/parsing/entities/trailing-semicolon/002.htm -- that is <img alt>... dunno if ie has different rules for <img src> or <a href>

[03:15:00.0000] <annevk>
could you another three columns for the non attribute case?

[03:17:00.0000] <annevk>
IE actually differs for &entity; &entity and &entityX

[03:17:01.0000] <zcorpan_>
sure

[03:17:02.0000] <annevk>
I suppose &entity means &entity< or something?

[03:18:00.0000] <annevk>
or maybe &entity followed by a space

[03:22:00.0000] <annevk>
what would be more useful I suppose if you checked the results using DOM methods and then just printed how they are supported... :)

[03:24:00.0000] <zcorpan_>
yeah

[03:32:00.0000] <hsivonen>
where might I find a list of characters that are allowed (per spec) in unquoted attribute values in HTML 4.01?

[03:32:01.0000] <annevk>
Should </br> also cause the active formatting elements to be reconstructed?

[03:33:00.0000] <hsivonen>
(without spending hours trying to grok SGML myself after borrowing the Handbook from a library)

[03:33:01.0000] <annevk>
I think it's [a-Z0-9]

[03:33:02.0000] <hsivonen>
annevk: what about hyphens, underscores and the like?

[03:35:00.0000] <annevk>
I'd think details would be in http://www.w3.org/TR/html4/appendix/notes.html

[03:35:01.0000] <annevk>
but it doesn't seem like it

[03:36:00.0000] <annevk>
"In certain cases, authors may specify the value of an attribute without any quotation marks. The attribute value may only contain letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons (ASCII decimal 58). We recommend using quotation marks even when it is possible to eliminate them."

[03:36:01.0000] <annevk>
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2

[03:37:00.0000] <hsivonen>
LCNMCHAR ".-_:"

[03:37:01.0000] <hsivonen>
yeah

[03:37:02.0000] <hsivonen>
thanks

[03:56:00.0000] <annevk>
bah

[03:56:01.0000] <annevk>
</br> is harder than it looks

[03:57:00.0000] <zcorpan_>
ok, the good news is that ie does the same thing with entities in attributes for both <img alt> and <a href>

[03:57:01.0000] <zcorpan_>
the bad news is that <img alt="&AElig"> works but <img alt="&AEligX"> doesn't

[03:58:00.0000] <zcorpan_>
need to figure out which characters end entities

[03:58:01.0000] <zcorpan_>
in attribute values

[04:01:00.0000] <annevk>
ah, that's only for attribute values?

[04:01:01.0000] <zcorpan_>
yeah

[04:01:02.0000] <annevk>
quoted versus double quoted versus unquoted too maybe?

[04:01:03.0000] <zcorpan_>
oh, that better work the same...

[04:01:04.0000] <zcorpan_>
but i'll test it too

[04:03:00.0000] <hsivonen>
when the generic facet of my validation service sees an XHTML 1.0 doctype in text/html, I will (in a future release) tokenize as HTML5 but validate as XHTML 1.0 and I'm going to say that this is bogus but I am doing it for the users' convenience

[04:03:01.0000] <hsivonen>
should I make the message a warning or an error?

[04:03:02.0000] <hsivonen>
"bogus" means error but "convenience" means warning

[04:03:03.0000] <zcorpan_>
error

[04:04:00.0000] <zcorpan_>
say that it isn't processed as xhtml by browsers unless the document is served with an xml mime type

[04:04:01.0000] <zcorpan_>
or something

[04:04:02.0000] <virtuelv>
annevk: doesn't most browsers interpret </br> as <br>?

[04:05:00.0000] <annevk>
yes

[04:05:01.0000] <hsivonen>
zcorpan_: makes sense.

[04:05:02.0000] <hsivonen>
annevk: do you have an opinion?

[04:06:00.0000] <annevk>
hsivonen, warning seems fine

[04:06:01.0000] <hsivonen>
zcorpan_: or would it make sense to turn it into a warning if the user checked the lax content type checkbox?

[04:06:02.0000] <annevk>
it's not actively harmful

[04:06:03.0000] <hsivonen>
/me is inclined to bind this to the lax type option

[04:08:00.0000] <hsivonen>
doh. I'm already doing something else for the lax type option, so that doesn't work

[04:10:00.0000] <zcorpan_>
hsivonen: with the lax option set, wouldn't you process it as xml?

[04:10:01.0000] <hsivonen>
zcorpan_: yes. I can't even remember anymore what the lax option does

[04:10:02.0000] <hsivonen>
the code for it is rather hairy, too

[04:11:00.0000] <zcorpan_>
in any case, when you parse xhtml with the html parser, emit an error imho

[04:11:01.0000] <hsivonen>
zcorpan_: ok

[04:11:02.0000] <zcorpan_>
if, with the lax option, you parse text/html as xml, a warning is fine

[04:12:00.0000] <zcorpan_>
back to entities: it seems any character except [a-zA-Z0-9] end an entity in attribute values

[04:17:00.0000] <annevk>
so you basically consume chars until you hit something out that range

[04:17:01.0000] <annevk>
hmm

[04:21:00.0000] <zcorpan_>
or you consume as many as possible that match the entity table, and for the longest match, check if the next character is in that range. if yes, emit the consumed characters, otherwise emit the entity

[04:24:00.0000] <annevk>
ok, rearchitected my </br> fix

[04:24:01.0000] <annevk>
should be easy to add </p> later

[04:25:00.0000] <annevk>
and _tons_ of other elements that act like that...

[04:25:01.0000] <annevk>
I love </plaintext>

[04:27:00.0000] <annevk>
zcorpan_, assuming the entity table doesn't have ; that should work I suppose

[04:28:00.0000] <zcorpan_>
yeah, the ; is not part of the entity name. we need to revert to the old table and instead have a third column that says which entities always require a ;

[04:29:00.0000] <annevk>
and a fourth that says which entities require that for attribute values...

[04:30:00.0000] <zcorpan_>
that is the same

[04:31:00.0000] <zcorpan_>
unless the next character is [a-zA-Z0-9], in which case all entities require a ;

[04:32:00.0000] <annevk>
how does that cover <a href="&region">&region</a>

[04:32:01.0000] <annevk>
oh right

[04:32:02.0000] <annevk>
interesting

[04:32:03.0000] <annevk>
what about & as terminating character and ?

[04:32:04.0000] <annevk>
or did you already try it for a big range?

[04:34:00.0000] <zcorpan_>
http://simon.html5.org/test/html/parsing/entities/trailing-semicolon/004.htm

[04:35:00.0000] <annevk>
good stuff :)

[04:36:00.0000] <annevk>
maybe you should use <span> instead of <a> for 003

[04:37:00.0000] <zcorpan_>
span doesn't have a href attribute :)

[04:37:01.0000] <annevk>
use title :)

[04:37:02.0000] <zcorpan_>
the point was to test a URI attribute

[04:37:03.0000] <annevk>
ok

[04:37:04.0000] <zcorpan_>
though i could use # if you don't want a lot of 404s :)

[04:38:00.0000] <annevk>
I suppose that could help

[04:39:00.0000] <zcorpan_>
done

[04:40:00.0000] <zcorpan_>
sent results to the list

[04:42:00.0000] <annevk>
heh, fun that you replied to my message :p

[04:42:01.0000] <annevk>
/me goes to fetch some food before it's gone

[04:44:00.0000] <zcorpan_>
i thought it was appropriate as a reply :)

[04:47:00.0000] <hsivonen>
does IE7 support &apos;?

[04:48:00.0000] <zcorpan_>
no

[04:48:01.0000] <hsivonen>
that's weird

[04:48:02.0000] <zcorpan_>
yes

[04:48:03.0000] <zcorpan_>
iirc i filed a bug on that during their "beta" stage

[04:49:00.0000] <hsivonen>
gotta remember to make it a warning

[04:49:01.0000] <zcorpan_>
http://simon.html5.org/test/ie7b2-bugs/014.html

[04:49:02.0000] <zcorpan_>
opera doesn't support &TRADE;

[04:50:00.0000] <hsivonen>
/me adds a note in the source

[04:50:01.0000] <zcorpan_>
annevk: is there a bug on that? (can i check that? :P )

[05:09:00.0000] <hsivonen>
/me wonders what's the best practice regarding memory allocation for growable buffers in a reusable library class

[05:10:00.0000] <hsivonen>
that is, should I optimize speed and risk memory leaks?

[05:10:01.0000] <hsivonen>
never leak memory and risk speed?

[05:10:02.0000] <hsivonen>
or let the user of the library decide?

[05:11:00.0000] <hsivonen>
annevk: does html5lib ever shrink buffers that grow depending on input? or does Python make these decisions for you?

[05:19:00.0000] <annevk>
zcorpan_, Opera does

[05:19:01.0000] <annevk>
zcorpan_, fetch a newer build now you can ;)

[05:20:00.0000] <annevk>
hsivonen, I'm not competent enough to answer that question

[05:20:01.0000] <annevk>
hsivonen, I can say as much as that we don't have weird constraints anywhere to my knowledge

[05:22:00.0000] <hsivonen>
annevk: ok

[06:06:00.0000] <annevk>
onload is broken in Safari: http://www.howtocreate.co.uk/safaribenchmarks.html ?

[06:06:01.0000] <annevk>
you'd think that if onload is broken pages would be broken as well...

[06:38:00.0000] <Fuzzy76>
I guess "broken" is a subjective term

[06:39:00.0000] <annevk>
it certainly explains the statistics on the safari download page...

[06:39:01.0000] <Fuzzy76>
yes... I've seen several other benchmarks, and none of them showed anything NEAR the numbers from Apple.

[07:12:00.0000] <annevk>
can someone explain to me how "After DOCTYPE public identifier state" and "Before DOCTYPE system identifier state" are different?

[07:12:01.0000] <annevk>
seems like they could be merged

[07:13:00.0000] <annevk>
i'll keep the separate for now...

[07:16:00.0000] <Philip`>
/me wonders if there's a reliable way to get multiple asynchronous XMLHttpRequests in flight at once (so the frequency of response arrival can be faster than the round-trip time)

[07:29:00.0000] <annevk>
wtf

[07:29:01.0000] <annevk>
doctype name is no longer uppercase?!

[07:29:02.0000] <annevk>
uppercased*

[07:29:03.0000] <annevk>
this is problematic

[07:31:00.0000] <annevk>
seems to be what Firefox does

[07:31:01.0000] <annevk>
but the amount of testcases that relies on this quirk...

[07:35:00.0000] <annevk>
/me fixes tests

[07:47:00.0000] <annevk>
Soonish people should be able to use html5lib to determine whether a page will render in quirks or standards mode

[07:49:00.0000] <mpt>
zcorpan_, what if someone really does want to style the <head> (e.g. head, title {display: block} title {font-size: 2em;})?

[07:53:00.0000] <annevk>
you don't need a scoped style sheet for that

[07:55:00.0000] <Philip`>
(Hmm, I can't fix my problem with XMLHttpRequest, but I can dynamically add <script> elements to the page while cycling through server port numbers so it has one outstanding request per port, since the scripts appear to get loaded asynchronously)

[07:56:00.0000] <Philip`>
(Oh, but they're only asynchronous in Firefox, not Opera, so that won't simply work. But XMLHttpRequest appears to do pipelining in Opera, so I just need to switch between the two methods. And work out what to do for Safari...)

[08:00:00.0000] <Philip`>
/me can't quite find what HTML5 says should happen in terms of synchrony when adding a (non-async) <script> to the DOM

[08:02:00.0000] <Philip`>
Oh, looks like it ought to be asynchronous, since the pausing is only done inside the tree construction algorithm

[08:07:00.0000] <zcorpan_>
mpt: if scoped stylesheets are changed to not affect their parent, then you couldn't use a scoped stylesheet for it anyway. and as anne says, you can already do that without scoped stylesheets

[08:08:00.0000] <zcorpan_>
btw, a girl here (at opera) will be implementing an html5 parser in c++

[08:08:01.0000] <Lachy>
IE's cryptic error javascript error messages are really annoying :-(

[08:08:02.0000] <Lfe>
zcorpan_: i would like her even more if she somehow left out those pluses ^_^

[08:09:00.0000] <zcorpan_>
Lfe: heh

[08:09:01.0000] <Lachy>
I'm writing a test case to test the toUpperCase and toLowerCase functions in JavaScript against the unicode data file

[08:10:00.0000] <Philip`>
Could provide a C API around the C++ implementation, so it's easily embeddable in other languages (like C, or Python ctypes, or whatever)

[08:10:01.0000] <Lachy>
so far, I've identified 3 bugs in Firefox within the first 500 chars (cause it takes far too long to process all 17000)

[08:13:00.0000] <met_>
looks like people are confused by all those storages http://ajaxian.com/archives/firefox-3-sqlite-and-more

[08:41:00.0000] <zcorpan_>
http://simon.html5.org/temp/html5-opera.txt are things that i might write tests for this summer (thought probably less that that, that's just a first filtering)

[08:42:00.0000] <zcorpan_>
anyone want me to look at something in particular?

[08:50:00.0000] <hsivonen>
annevk: I haven't implemented anything that is in the tree construction part (yet)

[08:59:00.0000] <annevk>
ah

[08:59:01.0000] <annevk>
i just landed all that's needed to enable quirks mode checking

[08:59:02.0000] <annevk>
someone just has to hook in some flag

[09:00:00.0000] <annevk>
/me hopes jgraham can make it look prettier

[09:01:00.0000] <annevk>
and we need to update the DOCTYPE token to handle systemId and publicId in case they are not None

[09:02:00.0000] <zcorpan_>
comments before the doctype don't trigger quirks mode per html5? even bogus comments? iirc this triggers quirks mode in firefox: </ foo ><!doctype html>

[09:02:01.0000] <zcorpan_>
but <? foo ><!doctype html> is standards mode

[09:03:00.0000] <annevk>
</ foo><!doctype html> doesn't in Opera

[09:03:01.0000] <annevk>
doesn't give you a comment token either

[09:05:00.0000] <zcorpan_>
</ foo><!doctype html> is quirks mode in ie7

[09:07:00.0000] <Philip`>
XXX<!doctype html> is standards mode in FF too

[09:07:01.0000] <Philip`>
(unless that > is pushed beyond the first 1024 bytes)

[09:08:00.0000] <annevk>
So Firefox is sniffing before actual parsing?

[09:09:00.0000] <annevk>
Guess that's why it's called "doctype sniffing" here and there

[09:09:01.0000] <zcorpan_>
Philip`: :-O wow, i don't think that was the case before

[09:09:02.0000] <zcorpan_>
annevk: yeah

[09:11:00.0000] <zcorpan_>
Philip`: or perhaps i just didn't test that case

[09:11:01.0000] <hsivonen>
annevk: or you could put JSON nulls in the array for public and system id when not present

[09:12:00.0000] <hsivonen>
annevk: since that handles nicely the cases when only one is absent

[09:12:01.0000] <hsivonen>
annevk: and you need to know which on

[09:12:02.0000] <hsivonen>
e

[09:12:03.0000] <hsivonen>
Philip`: that's weird. IIRC, around Mozilla 1.1 it wasn't like that.

[09:12:04.0000] <Philip`>
It looks like FF must be doing some look-ahead before parsing - compare <!--><!doctype html> vs <!--><!doctype xhtml>

[09:12:05.0000] <annevk>
hsivonen, that's for the tokenizer tests

[09:13:00.0000] <annevk>
hsivonen, I was thinking about the tree construction stage

[09:13:01.0000] <hsivonen>
oh

[09:13:02.0000] <annevk>
maybe I should handle the tokenizer tests first, prolly easier to make testcases too

[09:22:00.0000] <annevk>
hsivonen, should I use None in the tests?

[09:23:00.0000] <hsivonen>
annevk: yes

[09:23:01.0000] <hsivonen>
annevk: I'm assuming that your JSON impl. maps None to JSON null

[09:24:00.0000] <annevk>
I'm talking about the test format

[09:24:01.0000] <hsivonen>
annevk: tree tests?

[09:25:00.0000] <annevk>
tokenizer tests

[09:26:00.0000] <annevk>
http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/

[09:27:00.0000] <hsivonen>
annevk: JSON null please

[09:27:01.0000] <annevk>
that throws an error somewhere else

[09:28:00.0000] <hsivonen>
annevk: in your JSON to Python mapper?

[09:29:00.0000] <hsivonen>
I'd expect a correct doctype to look like this: ["DOCTYPE", "HTML", null, null, false]

[09:29:01.0000] <annevk>
the last one should be true I think

[09:29:02.0000] <annevk>
as the flag is now "correct"

[09:29:03.0000] <hsivonen>
argh.

[09:29:04.0000] <hsivonen>
annevk: you are right, of course

[09:30:00.0000] <Philip`>
More specifically: FF seems to do standards mode if the first 1024 characters from the first non-whitespace character onwards, parsed using quirks mode rules, contains at least one doctype, and the first doctype is a valid HTML one and is not preceded by any non-comment non-text nodes

[09:30:01.0000] <annevk>
it seems all tests were a bit bogus with respect to that

[09:30:02.0000] <Philip`>
(or something roughly like that)

[09:31:00.0000] <zcorpan_>
Philip`: you sure parsing is in quirks mode initially?

[09:31:01.0000] <zcorpan_>
/me should be heading home now so he doesn't miss the train

[09:32:00.0000] <Philip`>
I think so - <!--><!doctype html><!--> results in two empty comments, instead of one comment with the text "><!doctype html><!" in it

[09:32:01.0000] <annevk>
ah ok

[09:32:02.0000] <annevk>
I didn't have simplejson and hence I got some simplified json parser that didn't get null

[09:32:03.0000] <zcorpan_>
but is the document standards mode or quirks mode?

[09:32:04.0000] <annevk>
implemented null in it now

[09:33:00.0000] <zcorpan_>
if quirks mode then the parser is initially in standards mode -- otherwise you would have seen the doctype in the pre-parse and switched to standards mode

[09:33:01.0000] <annevk>
Philip`, <!--> should always be a single comment

[09:33:02.0000] <zcorpan_>
i might have written something about this at sitepoint forums at some point

[09:34:00.0000] <zcorpan_>
anyway, i'm leaving now

[09:34:01.0000] <zcorpan_>
/me waves

[09:34:02.0000] <Philip`>
If I do <!doctype html><!--><!doctype html><!--> then it is CSS1Compat and it says "#comment: ><!doctype html><!"

[09:35:00.0000] <Philip`>
If I do <!--><!doctype html><!--> then it is BackCompat and it says "#comment","#comment"

[09:36:00.0000] <Philip`>
so... it's parsing in standards mode, not finding the doctype, then re-parsing in quirks mode (and finding the doctype but not changing mode)?

[09:37:00.0000] <annevk>
I have updated some of the tests

[10:38:00.0000] <annevk>
I fixed all the DOCTYPE tests and the tokenizer part of the implementation. I also added some more tokenizer tests to cover PUBLIC and SYSTEM ids.

[10:45:00.0000] <rubys>
annevk: you've been busy!  :-)

[10:46:00.0000] <annevk>
yeah, I feel a bit sorry for the ruby project

[10:46:01.0000] <rubys>
nah, won't be hard to catch up, the divs on the python code points the way.

[10:46:02.0000] <annevk>
cool

[10:47:00.0000] <annevk>
There are still some things to implement such as proper DOCTYPE tokens

[10:47:01.0000] <rubys>
i'd like to wait to resync until you slow down... 

[10:48:00.0000] <annevk>
I'm about to go home

[10:48:01.0000] <annevk>
so go ahead :)

[10:48:02.0000] <rubys>
cool, and I see the python tests are passing, which is a good sign.

[10:52:00.0000] <annevk>
yeah, I fixed the tests along with the implementation although 3 are still failing

[10:52:01.0000] <annevk>
I hope Thomas can fix that

[10:52:02.0000] <rubys>
i don't see any failing... which ones fail for you?

[10:52:03.0000] <annevk>
some sanitize and serializer tests

[10:53:00.0000] <rubys>
I just tried again... no failures.

[10:53:01.0000] <annevk>
hmm ok

[10:54:00.0000] <annevk>
maybe I'm missing something

[11:36:00.0000] <annevk>
jgraham, have you looked at handling "comments" within RCDATA and CDATA blocks?

[11:36:01.0000] <annevk>
jgraham, seems like we need some character buffer

[12:18:00.0000] <jgraham>
annevk: I was going to ask you the same thing :)

[12:18:01.0000] <jgraham>
I haven't, yet

[12:18:02.0000] <jgraham>
As I've been a bit busy

[12:18:03.0000] <jgraham>
I was happy to see all your checkins today though

[12:54:00.0000] <zcorpan_>
Philip`: yes, exactly

[12:59:00.0000] <Jero>
off topic: what do you guys think of this design? http://jero.net/lab/redesign2/

[13:09:00.0000] <zcorpan_>
Jero: looks a bit like a standard template for a blog

[13:11:00.0000] <Jero>
well, it is a blog ;), but i see what you mean

[13:12:00.0000] <Jero>
I'll probably have to dust off my Photoshop skills and try to come up with something original

[13:24:00.0000] <Hixie>
annevk: we could define almost standards mode, but there'd be absolutely no detectable conformance criteria in the spec for it :-/

[13:24:01.0000] <Hixie>
hsivonen: i thought the table _was_ sorted

[13:34:00.0000] <Jero>
for all those who care: I now implemented the entire tokenization and tree construction algorithms in my HTML5 parser in PHP (http://jero.net/lab/ph5p/)

[13:34:01.0000] <Jero>
now to get rid of those bugs (http://jero.net/lab/ph5p/tests.html)

[13:35:00.0000] <Jero>
(and optimizing might not be such a bad idea)

[13:39:00.0000] <rubys>
jero: have you taken a look at html5lib's testdata directory?

[13:40:00.0000] <Jero>
not recently, but the tests in my tests.html file are from the first test file

[13:51:00.0000] <Hixie>
annevk: defined almost standards mode

[14:28:00.0000] <Hixie>
jesus, <nobr> is wacked in html parsers

[14:28:01.0000] <Hixie>
how are we gonna handle _that_

[14:29:00.0000] <Dashiva>
Compared to what parsers?

[14:32:00.0000] <Hixie>
how do you mean?

[14:33:00.0000] <Dashiva>
Just wondered if there was somewhere it wasn't wacked, since you qualified the statement like that

[14:38:00.0000] <Hixie>
Dashiva: oh well like xml parsing

[15:09:00.0000] <Hixie>
hsivonen: yt?

[15:46:00.0000] <Philip`>
Hmph, now I need to do canvas text rendering :-(

[16:03:00.0000] <Hixie>
http://lists.w3.org/Archives/Public/public-html/2007Jun/0375.html

[16:03:01.0000] <Hixie>
o_O

[16:53:00.0000] <Hixie>
/me wonders how it is "frequently unclear whether a suggestion is aimed at the language definition or at the browser behaviour specification"

[16:53:01.0000] <Hixie>
isn't it pretty obvious?

[16:55:00.0000] <jgraham>
Hixie: From Phillip's mail to public-html? That whole email made no sense to me.

[16:55:01.0000] <Hixie>
i have to say i generally understand mails to whatwg a whole lot better than those to p-h

[16:56:00.0000] <Hixie>
it's kinda annoying since it makes it harder for me to deal with the p-h ones

[16:57:00.0000] <jgraham>
whatwg (still) seems to be where all the work is getting done... maybe we can change the tag line to "Putting the 'work' into working group" or somesuch ;)

[16:58:00.0000] <Hixie>
no comment


2007-06-19
[17:00:00.0000] <jgraham>
I'm joking of course...

[17:00:01.0000] <jgraham>
And, I think it is generally obvious what is a document conformance requirement and what is a US requirement

[17:01:00.0000] <jgraham>
I also think the spec makes for a poor reference for authors

[17:01:01.0000] <Hixie>
it certainly makes a poor reference to anyone who isn't technically minded

[17:02:00.0000] <Hixie>
i'm not really skilled enough to write text that is both unambiguous and clear to non-technical people, sadly

[17:37:00.0000] <Hixie>
ok so my experience with JAWS is somewhat poor

[17:37:01.0000] <Hixie>
i can't even get past the first screen of the installer without accessibility problems

[17:41:00.0000] <Hixie>
ok, got it past the first screen by cheating

[17:42:00.0000] <Hixie>
it installed stuff, then said it had to reboot, and then crashed my machine hard.

[17:42:01.0000] <Hixie>
had to hard-power-reset it

[18:18:00.0000] <Hixie>
holy fornicating rabbits, if jaws is the state of the art in speech reading software i'm not _surprised_ that accessibility people are so cranky

[18:18:01.0000] <Hixie>
sweet jesus

[19:45:00.0000] <Dashiva>
I thought m12n was bad enough, now we have a11y?

[19:57:00.0000] <karlUshi>
for a long time it seems http://www.google.com/search?q=a11y

[21:49:00.0000] <Hixie>
wow, the DOM that IE makes for  <!DOCTYPE HTML><form>  sure is... inretesting

[22:31:00.0000] <hsivonen>
Hixie: I'm awake now

[22:34:00.0000] <Hixie>
hsivonen: i replied to mail instead

[22:35:00.0000] <hsivonen>
Hixie: ok

[23:05:00.0000] <Hixie>
nearly done with this doctype thread

[23:05:01.0000] <Hixie>
sheesh

[23:10:00.0000] <Hixie>
yay, finally done with it

[23:24:00.0000] <Hixie>
i wonder why the definition for the HTML innerHTML setter starts with "Otherwise,"

[23:42:00.0000] <hsivonen>
/me finds out he followed up to a post with already a large number of follow-ups that weren't properly threaded. :-(

[00:20:00.0000] <hsivonen>
annevk: my impl passed html5lib/testdata/tokenizer/test1.test on the first try after the new doctype stuff. yay

[00:22:00.0000] <hsivonen>
test2.test revealed one bug. fixed

[00:40:00.0000] <Hixie>
you guys have already got that implemented?

[00:40:01.0000] <Hixie>
sheesh

[00:40:02.0000] <Hixie>
talk about bleeding edge

[00:42:00.0000] <hsivonen>
Hixie: well, I implemented the tokenization part--not yet the tree builder part

[00:42:01.0000] <Hixie>
ah ok

[00:44:00.0000] <zcorpan_>
</><!doctype html> is another interesting case (because the token doesn't reach the tree construction stage). though handled the same as </ foo ><!doctype html> in browsers

[00:45:00.0000] <Hixie>
yeah i

[00:45:01.0000] <Hixie>
er

[00:46:00.0000] <Hixie>
yeah i'm sure there are lots of edge cases that act slightly differently between the spec and browsers

[00:46:01.0000] <Hixie>
those are usually the cases that aren't really important and that the browsers all do differently anyway

[00:46:02.0000] <zcorpan_>
perhaps

[00:57:00.0000] <hsivonen>
people say that authors know HTML 4.01 and, therefore, they want to know the diff to HTML 5, but commentary suggests that usually people don't really know the HTML 4.01 details. witness optional tags

[00:58:00.0000] <Hixie>
i keep saying that

[00:58:01.0000] <Hixie>
people don't believe me though

[00:59:00.0000] <othermaciej>
I love the people staring at gape-jawed horror at the optional tags

[01:00:00.0000] <othermaciej>
and suggesting that XML syntax is a good way to teach HTML

[01:00:01.0000] <othermaciej>
*shudder*

[01:01:00.0000] <zcorpan_>
Hixie: the doctype 1024 bytes thing is firefox, not opera or ie. dunno about safari. reproducable from local disk

[01:01:01.0000] <Hixie>
zcorpan_: yeah, i reproduced it eventually myself too (with your help)

[01:01:02.0000] <karlUshi>
othermaciej: it is. XHTML syntax makes it a lot easier. believe me.

[01:01:03.0000] <karlUshi>
By experience

[01:01:04.0000] <karlUshi>
I have taught both languages

[01:02:00.0000] <Hixie>
zcorpan_: doesn't seem to happen for only spaces, only happens if there's some thing before the doctype other than whitespace

[01:02:01.0000] <othermaciej>
karlUshi: the problem is if you assume XML syntax actually applies

[01:02:02.0000] <othermaciej>
and start doing things like <div id="placeholder" />

[01:02:03.0000] <othermaciej>
or <script src="foo.js" />

[01:03:00.0000] <Hixie>
btw, the html5 parser spec is starting to get good enough that when people report bugs with them, it's usually the case that the bug is actually in one browser and that most of hte other browsers don't have that quirk

[01:03:01.0000] <karlUshi>
but it is not what people do :) this is a geek comment.

[01:03:02.0000] <zcorpan_>
Hixie: you can have whitespace within the doctype, with nothing before the doctype. if the > is not within the first 1024 bytes then firefox gets quirks mode

[01:03:03.0000] <Hixie>
<script src="foo.js" /> is far too common

[01:03:04.0000] <Hixie>
so common we might have to in fact put it in the spec, though i really hope not

[01:03:05.0000] <othermaciej>
<canvas /> is also distressingly common

[01:04:00.0000] <othermaciej>
/me apologizes for that one

[01:04:01.0000] <karlUshi>
hehe

[01:04:02.0000] <Hixie>
zcorpan_: i had 1024 x ' ' followed by a doctype and i got standards mode. but a bogus comment then 1024 x ' ' then the doctype, and it's quirks.

[01:04:03.0000] <Hixie>
othermaciej: not so much on the web, only mostly in dashboard widgets, thankfully

[01:04:04.0000] <karlUshi>
/me is going to look for his whips in the closets. oh and ropes

[01:04:05.0000] <othermaciej>
karlUshi: teaching people that some tags don't need a close tag seems simpler to me than teaching them that <foo /> is a self-closing tag, but can only be used for a fixed small set of tags

[01:04:06.0000] <karlUshi>
it is not because it depends on the tag

[01:05:00.0000] <othermaciej>
karlUshi: even though the XML spec you are nominally following says it can be used for anything

[01:05:01.0000] <zcorpan_>
Hixie: i don't get standards mode with 1024 x ' ' followed by a doctype in firefox

[01:05:02.0000] <othermaciej>
I agree that XML syntax would be easier to teach if you could actually use XML syntax

[01:05:03.0000] <othermaciej>
but as it is, teaching a well-structured version of HTML syntax seems better

[01:05:04.0000] <karlUshi>
plus things like I was typing yesterday on the channel

[01:05:05.0000] <othermaciej>
(i.e. tell people to close non-empty tags that don't need it to avoid confusion)

[01:09:00.0000] <zcorpan_>
Hixie: or wait, nm, you're right

[01:10:00.0000] <karlUshi>
weeeell, from my *practical* teaching experience,  xhtml rules create far less misunderstanding. and what I heard from most teachers is the same. But we might have had different contacts with different people

[01:11:00.0000] <othermaciej>
a lot of people writing XHTML don't understand that the browser is not going to use an XML parser

[01:11:01.0000] <othermaciej>
(possibly most)

[01:12:00.0000] <karlUshi>
here again you see it on the geek side. 

[01:13:00.0000] <karlUshi>
it is not relevant for most people to know which parser is used.

[01:13:01.0000] <karlUshi>
but for web developers when reading and maintaining the code it is relevant

[01:13:02.0000] <karlUshi>
hmmm

[01:13:03.0000] <karlUshi>
I have something in my head to publish on HTML viewed from different angles

[01:13:04.0000] <karlUshi>
and people refusing to accept the other camps

[01:14:00.0000] <karlUshi>
it is kind of funny because I do the same kind of arguments on both sides

[01:14:01.0000] <othermaciej>
here's the thing, it's not just that people are unsure

[01:14:02.0000] <othermaciej>
they are deeply factually convinced that XHTML is parsed as XML when served as text/html, or that at least it should be

[01:14:03.0000] <othermaciej>
even prominent w3c working group members are often confused on this point

[01:15:00.0000] <hsivonen>
Hixie: I definitely didn't mean to ask for a 1024 char limit when I asked for doing what Gecko and WebKit do

[01:15:01.0000] <karlUshi>
it is not a problem for web developers :)

[01:15:02.0000] <othermaciej>
when many people actively believe something false, that says to me there is a problem

[01:15:03.0000] <othermaciej>
if web developers choose not to think about it that is one thing, but like I said many have an active belief that is contrary to fact

[01:16:00.0000] <Hixie>
othermaciej: even w3c xhtml2 working group members are often confused on this point! and they invented the spec in question!

[01:16:01.0000] <Hixie>
hsivonen: ah ok

[01:16:02.0000] <Hixie>
hsivonen: good :-)

[01:16:03.0000] <othermaciej>
if I believed my CPU was a PPC chip not an Intel chip, it probably wouldn't matter to me most of the time

[01:16:04.0000] <othermaciej>
but the times that it does, it would seriously mess me up

[01:16:05.0000] <othermaciej>
especially if I refused to accept evidence that it was indeed an Intel chip

[01:17:00.0000] <hsivonen>
othermaciej: :-)

[01:17:01.0000] <karlUshi>
othermaciej: good example. When does it really matter? I'm really curious.

[01:17:02.0000] <karlUshi>
/me having is life on macs for more than 10 years now

[01:17:03.0000] <Hixie>
annevk: yt?

[01:18:00.0000] <othermaciej>
karlUshi: as a developer, I have to care when writing inline assembly code, which is rare but sometimes necessary

[01:18:01.0000] <zcorpan_>
karlUshi: people use things like <span/> and expect it to close itself

[01:18:02.0000] <Hixie>
annevk: so you asked for <!-->--> to be treated like <!--->--&gt;

[01:18:03.0000] <karlUshi>
othermaciej: here again, talking about ubergeeks

[01:18:04.0000] <Hixie>
annevk: but it turns out only IE does that in no-quirks mode

[01:18:05.0000] <othermaciej>
karlUshi: as a user, I need to realize that PPC-only binaries will be running in emulation and so will be slower and will use a lot of memory

[01:18:06.0000] <othermaciej>
karlUshi: well, most people don't have to care what their CPU is

[01:18:07.0000] <Hixie>
annevk: so, do we want to change no-quirks-mode comment parsing, or do we want to introduce a quirks-mode tokeniser difference?

[01:18:08.0000] <karlUshi>
people who deals with xslt and xquery etc. Yes I agree with you will have to know what is XML

[01:19:00.0000] <karlUshi>
not most web developers

[01:19:01.0000] <othermaciej>
karlUshi: but if you call tech support and tell them you have a PowerPC chip instead of "I don't know", you could have problems

[01:19:02.0000] <othermaciej>
it's better not to know than to be convinced of the wrong thing

[01:19:03.0000] <othermaciej>
if you don't know, at least you know that you should look it up if you need to know

[01:19:04.0000] <zcorpan_>
Hixie: the former, imho, unless it breaks pages

[01:20:00.0000] <Hixie>
i wonder how to find out whether it breaks pages

[01:20:01.0000] <Hixie>
hm

[01:20:02.0000] <karlUshi>
Many people say they machine name  at best, (sometimes the color and the shape) and when they bought it. The rest is

[01:20:03.0000] <annevk>
am now

[01:20:04.0000] <annevk>
Hixie, I think if IE does it it should be safe enough for other browsers

[01:21:00.0000] <annevk>
<!--> and <!---> btw

[01:21:01.0000] <Hixie>
(yeah)

[01:21:02.0000] <Hixie>
hmm

[01:21:03.0000] <Hixie>
that's a plausible argument i guess

[01:21:04.0000] <annevk>
it is for parsing

[01:21:05.0000] <Hixie>
right then

[01:21:06.0000] <othermaciej>
karlUshi: right, many people don't know what their CPU is, but few are certain that it's something other than what it is

[01:21:07.0000] <annevk>
if this was about DOM methods...

[01:22:00.0000] <Hixie>
we'll see what browser vendors say when they try to implement it! :-)

[01:22:01.0000] <hsivonen>
karlUshi: even if people don't know which CPU they have, they aren't vehemently believing that they have a different CPU than what they actually have

[01:24:00.0000] <karlUshi>
interesting, I hear people from this group asking for being real with people, and then sometimes to have people to require extreme knowledge of the technology... when obviously xhtml syntax rules worked for most people and made them developer beautiful xhtml/css web sites. :)

[01:24:01.0000] <karlUshi>
not. logical. at. all.

[01:24:02.0000] <karlUshi>
anyway

[01:24:03.0000] <karlUshi>
need to move my butt to the train

[01:25:00.0000] <hsivonen>
/me wonders how misrepresenting testable facts is being real

[01:25:01.0000] <hsivonen>
(i.e. teaching people that XHTML as text/html gets an XML treatment)

[01:26:00.0000] <annevk>
I wonder what the difference is between learning for which tags you can write <foo/> and for which you always have to write <bar></bar> and learning HTML

[01:26:01.0000] <othermaciej>
because the former is well-formed XML and the latter is tag soup

[01:26:02.0000] <hsivonen>
on the bright side, even if XHTML brings out irrational beliefs it doesn't make people as hostile as syndication feeds :-)

[01:27:00.0000] <annevk>
othermaciej, I see it now, makes perfect sense!

[01:29:00.0000] <othermaciej>
/me takes a bow

[01:30:00.0000] <weinigLap>
claps

[01:30:01.0000] <Hixie>
ok this comment thing is going to be a bitch

[01:30:02.0000] <annevk>
http://validator.whatwg.org/ is cool!

[01:30:03.0000] <Hixie>
to get the right parse errors i have to add two new states!

[01:30:04.0000] <Hixie>
annevk: heh, it's been there since forever (though it used to give a 403)

[01:30:05.0000] <Hixie>
but the link seemed useful, indeed

[01:38:00.0000] <MikeSmith>
so what reason do you give to those already indoctrinated in closing-tag-required-on-empty-elements for why <script src="foo.js" /> is not conformant?

[01:40:00.0000] <annevk>
MikeSmith, IE doesn't support that?

[01:40:01.0000] <annevk>
nor do lots of older browsers

[01:41:00.0000] <annevk>
it's not backwards compatible at all

[01:41:01.0000] <Hixie>
MikeSmith: they're writing HTML4. And it's not conforming HTML4.

[01:42:00.0000] <Hixie>
MikeSmith: for the same reason that {script} isn't conforming HTML4. it's just not HTML4's syntax.

[01:49:00.0000] <MikeSmith>
or to point out that you can create a well-formed, valid XHTML1 document that is no HTML4-conformant ... ?

[01:50:00.0000] <MikeSmith>
not HTML4-conformant

[01:50:01.0000] <othermaciej>
it's pretty hard to make a document that's both conforming XHTML1 and conforming HTML4

[01:50:02.0000] <annevk>
it's impossible

[01:50:03.0000] <zcorpan_>
annevk: nope, you can play with PIs

[01:51:00.0000] <zcorpan_>
they end with > in html and ?> in xml

[01:51:01.0000] <annevk>
/me wonders how that would solve stuff

[01:51:02.0000] <Hixie>
it is indeed possible, though not at all useful

[01:51:03.0000] <hsivonen>
IIRC, there's one on damowmow

[01:51:04.0000] <Hixie>
indeed

[01:52:00.0000] <Hixie>
http://damowmow.com/playground/html-or-xml.html

[01:52:01.0000] <Hixie>
http://damowmow.com/playground/html-or-xml.xml

[01:52:02.0000] <Hixie>
(same file)

[01:52:03.0000] <Hixie>
technically it's not conforming to either HTML4 nor XHTML1, but it validates as both

[01:53:00.0000] <zcorpan_>
Hixie: why is it not conforming?

[01:53:01.0000] <Hixie>
PIs aren't allowed

[01:53:02.0000] <Hixie>
iirc

[01:56:00.0000] <annevk>
Hixie, do you want replies to e-mails where I agree with your response (even if phrased as question)?

[01:56:01.0000] <annevk>
/me isn't keen on flooding the list with "Yeah", "Yeah", ...

[01:57:00.0000] <annevk>
Hixie, cool

[01:57:01.0000] <hsivonen>
is a conforming application of SGML allowed to ban PIs?

[01:57:02.0000] <hsivonen>
/me guesses no

[01:57:03.0000] <hsivonen>
/me assumes HTML 4.01 isn't conforming

[01:58:00.0000] <zcorpan_>
html4 says that authors are discouraged from using sgml features with little support in html uas, or some such

[01:58:01.0000] <zcorpan_>
don't think xhtml bans pis

[01:59:00.0000] <zcorpan_>
except in appendix c

[02:01:00.0000] <Hixie>
annevk: no, don't bother sending mail unless you want me to change the spec

[02:01:01.0000] <Hixie>
(i mean, you can, but i'm not tracking the issues that i've replied to, so it doesn't really do much)

[02:02:00.0000] <annevk>
good

[02:04:00.0000] <hsivonen>
/me still does not understand why Java JSON impls don't inherit JSONArray from LinkedList and JSONObject from HashMap

[02:05:00.0000] <othermaciej>
wouldn't you want an array to be an array, instead of a linked list?

[02:05:01.0000] <annevk>
Hixie, thanks for aligning the quirks mode sniffing with the html5lib implementation (whether intentional or not)

[02:06:00.0000] <othermaciej>
also, wouldn't restricting the allowed key/value types for HashMap violate the Liskov Substitution Principle?

[02:07:00.0000] <hsivonen>
othermaciej: given what "array" means in JSON, the obvious mutable Java mapping is an instance of the List interface

[02:08:00.0000] <othermaciej>
hsivonen: I'm assuming an array in JSON is much like a JavaScript Array

[02:08:01.0000] <othermaciej>
which is a sparse array, not a linked list

[02:08:02.0000] <othermaciej>
/me is not sure if JSON allows the elision syntax, if not, it's non-sparse

[02:09:00.0000] <hsivonen>
othermaciej: not having a JSONValue common subtype indeed would make generics with JSONArray and JSONObject ugly, but having those take java.lang.Objects with magic restrictions would eliminate annoying boxing code

[02:10:00.0000] <hsivonen>
othermaciej: as far as I can tell, JSONArray is conceptually a java.util.List

[02:10:01.0000] <hsivonen>
othermaciej: doesn't matter if it is backed by LinkedList or ArrayList

[02:10:02.0000] <othermaciej>
well, performance-wise it does

[02:10:03.0000] <othermaciej>
it's almost never good to use a linked list instead of an array

[02:11:00.0000] <hsivonen>
of course, but in API terms both are better than this boxing/unboxing drudgery I have to deal with

[02:11:01.0000] <othermaciej>
/me wonders what the difference is between ArrayList and Vector

[02:11:02.0000] <Hixie>
annevk: what did i change?

[02:11:03.0000] <hsivonen>
othermaciej: ArrayList doesn't do synchronized on its own

[02:12:00.0000] <hsivonen>
Vector is part of the overly thread-safe legacy

[02:12:01.0000] <othermaciej>
I see

[02:12:02.0000] <hsivonen>
would be cool to update onvdl to use non-synchronized collections some day

[02:13:00.0000] <annevk>
Hixie, the formatting and moving down the two doctypes for which the systemid has to be missing

[02:15:00.0000] <Hixie>
/me looks up the Liskov substitution principle and wonders why it has such a fancy name instead of being called "common sense"

[02:15:01.0000] <Hixie>
annevk: i did it purely for readability reasons, but i'm glad it made things better :-)

[02:16:00.0000] <othermaciej>
Hixie: people shows more respect if you use a fancy term instead of saying "that violates common sense"

[02:16:01.0000] <Hixie>
fair point

[02:17:00.0000] <Hixie>
i had the same reaction when i learnt of De Morgan's laws at university

[02:18:00.0000] <hsivonen>
If I some day write my own JSON mapper for Java, JSONString will be a straight java.lang.String, JSONArray will be java.util.List<Object> and JSONObject will be java.util.Map<String, Object>

[02:18:01.0000] <Hixie>
i was like "wait, this has a name? i've been doing this since i was 10"

[02:18:02.0000] <annevk>
whatwg.org down?

[02:19:00.0000] <Hixie>
it's having issues

[02:20:00.0000] <annevk>
oh well, there are two repositories now :)

[02:21:00.0000] <annevk>
maybe someone should get ambitious and make the html5.org tracker handle timeouts by switching repository

[02:21:01.0000] <Hixie>
http://www.dreamhoststatus.com/ usually has information about why whatwg.org or hixie.ch are down

[02:21:02.0000] <Hixie>
though not this time

[02:24:00.0000] <othermaciej>
hsivonen: yeah, too bad you can't make the generics quite exactly perfect without introducing a base class for simple values

[02:24:01.0000] <annevk>
it's back up it seems

[02:24:02.0000] <othermaciej>
I guess you have to either box primitive types and strings or make the interface a little looser than Java likes

[02:25:00.0000] <hsivonen>
othermaciej: the latter is so much nicer to program with

[02:25:01.0000] <hsivonen>
othermaciej: also, in this case, it would have made equal() sane by default

[02:25:02.0000] <hsivonen>
/me had to write an external JSON equality test

[02:25:03.0000] <othermaciej>
:-(

[02:25:04.0000] <hsivonen>
equals()

[02:26:00.0000] <hsivonen>
anyway, all that code is now done

[02:26:01.0000] <hsivonen>
and tests pass

[02:34:00.0000] <annevk>
Hixie, several changes such as &&, </ in <script>, etc. have only been updated in the parsing section and not in the "writing" equivalent sections

[02:35:00.0000] <Hixie>
oh, crap

[02:35:01.0000] <Hixie>
any idea what the "etc" are?

[02:36:00.0000] <annevk>
the other &... thingies

[02:36:01.0000] <annevk>
/me checks for more

[02:36:02.0000] <annevk>
that's it

[02:36:03.0000] <annevk>
although maybe <p>test</body> needs something... dunno

[02:55:00.0000] <Hixie>
good lord

[02:55:01.0000] <Hixie>
i can't work out how to write the requirements on magic cdata comment stuff for authors

[02:59:00.0000] <annevk>
you already did that

[03:09:00.0000] <Hixie>
turns out it's wrong

[03:10:00.0000] <Hixie>
it disallows <!-- <!-- -->

[03:11:00.0000] <annevk>
that makes me wonder what <!-- <!--> --> does

[03:11:01.0000] <Hixie>
it disallows that too

[03:12:00.0000] <Hixie>
both should be allowed

[03:12:01.0000] <annevk>
you can nest them?

[03:15:00.0000] <Hixie>
no

[03:15:01.0000] <Hixie>
<!-- <!--> --> is equivalent to <!- xx--> xxx

[03:36:00.0000] <Hixie>
right, fixed

[03:45:00.0000] <Hixie>
ugh http://bugs.webkit.org/show_bug.cgi?id=12646

[03:45:01.0000] <Hixie>
html5 breaking pages

[03:45:02.0000] <Hixie>
bummer

[03:49:00.0000] <zcorpan_>
is it <h3><h4> vs <h3><a><h4>?

[03:49:01.0000] <Hixie>
yes

[03:51:00.0000] <Hixie>
wait... IE lets you nest them anyway

[03:51:01.0000] <Hixie>
wtf

[03:52:00.0000] <zcorpan_>
indeed

[03:52:01.0000] <annevk>
the rendering doesn't change though

[03:52:02.0000] <annevk>
nested <h1> keep the same font size

[03:53:00.0000] <Hixie>
sure, because they use absolute font sizes

[03:53:01.0000] <annevk>
I suppose that might have been the reason for other browsers to not do the nesting

[03:53:02.0000] <zcorpan_>
<h1><p>

[03:53:03.0000] <Hixie>
we could do that too with the 'rem' units

[03:53:04.0000] <Hixie>
hah

[03:53:05.0000] <Hixie>
IE is weird

[03:54:00.0000] <Hixie>
all browsers do <h1><p> as nesting

[03:54:01.0000] <Hixie>
as does the spec

[03:54:02.0000] <zcorpan_>
ah, ok

[03:55:00.0000] <Hixie>
what should we do? allow header nesting and require the stylesheet to use 'rem' or 'px' units?

[03:55:01.0000] <Hixie>
or special-case <a>?

[03:55:02.0000] <Hixie>
hmm

[03:55:03.0000] <annevk>
<h1><p>x</h1>x :(

[03:56:00.0000] <Hixie>
":-(" ?

[03:56:01.0000] <annevk>
I get red text nodes in IE

[03:56:02.0000] <Hixie>
interoperable for me

[03:56:03.0000] <Hixie>
oh well yes

[03:56:04.0000] <Hixie>
IE goes red at a moment's notice

[03:56:05.0000] <annevk>
heh

[03:56:06.0000] <annevk>
I'd go for nested headers with rem I think...

[03:57:00.0000] <annevk>
(would be nice if rem took <body> into account...)

[03:58:00.0000] <Hixie>
it's sad since every other browser does it the same way

[03:58:01.0000] <hsivonen>
annevk: got tests for the crazy [R]CDATA escape flag?

[03:59:00.0000] <annevk>
yeah

[03:59:01.0000] <annevk>
tests5.dat

[03:59:02.0000] <annevk>
html5lib doesn't pass them though

[03:59:03.0000] <hsivonen>
annevk: ah. thanks. no tokenizer-level tests, though?

[04:00:00.0000] <hsivonen>
annevk: is it ok to write and check in some even if html5lib itself doesn't pass them yet?

[04:00:01.0000] <hsivonen>
annevk: shall I start a new file?

[04:00:02.0000] <annevk>
hsivonen, please make it a separate file

[04:00:03.0000] <hsivonen>
ok

[04:00:04.0000] <annevk>
hsivonen, I suppose some people want to disable it like they did with html5

[04:00:05.0000] <annevk>
euh, test5

[04:05:00.0000] <Hixie>
wouldn't tests that fail be the most useful kind of test?

[04:06:00.0000] <hsivonen>
Hixie: in TDD you want to pass tests--not fail :-)

[04:06:01.0000] <Hixie>
tdd?

[04:07:00.0000] <zcorpan_>
is the .constructor attribute specced anywhere? (can i use it in test cases?)

[04:07:01.0000] <Hixie>
zcorpan_: try ECMA262

[04:08:00.0000] <hsivonen>
Hixie: Test-Driven Development

[04:10:00.0000] <hsivonen>
argh. the % operator in Java is crazy

[04:10:01.0000] <hsivonen>
sane in Python

[04:10:02.0000] <Hixie>
ah

[04:10:03.0000] <Hixie>
well, sure, you want the tests to pass

[04:11:00.0000] <Hixie>
but when you write them they should fail

[04:11:01.0000] <Hixie>
new tests that pass seem pointless :-) (except for regression testing, of course, but that's boring :-P)

[04:11:02.0000] <hsivonen>
/me failed due to -1 % 4 resulting in -1 instead of 3

[04:12:00.0000] <zcorpan_>
Hixie: thanks

[04:13:00.0000] <Hixie>
/me comes across an e-mail showing yet another difference between IE and all other browsers

[04:13:01.0000] <Hixie>
<ol> <li> xxx </li> yyy </ol>

[04:13:02.0000] <zcorpan_>
yup

[04:13:03.0000] <Hixie>
i guess i'll sleep on it

[04:14:00.0000] <Hixie>
since we don't have a bug report for this one i'm tempted to leave it

[04:14:01.0000] <annevk>
I think we're fine with aligning more with IE

[04:14:02.0000] <zcorpan_>
in wysiwyg editors that use contentEditable or designMode, a nested list takes the form <ul><li>foo</li><ul><li>bar</li></ul></ul>

[04:14:03.0000] <Hixie>
if we don't, we'll end up putting comments and spaces in the wrong place

[04:14:04.0000] <Hixie>
zcorpan_: good times

[04:14:05.0000] <hsivonen>
/me makes his first check-in to html5lib

[04:14:06.0000] <zcorpan_>
if you write content with ie the end result is conforming because the </li> is ignored. if you write with other browsers the end result is non-conforming

[04:15:00.0000] <zcorpan_>
people blame other browsers

[04:15:01.0000] <Hixie>
yeah

[04:15:02.0000] <Hixie>
oh?

[04:15:03.0000] <Hixie>
uri to blame-giving?

[04:15:04.0000] <Hixie>
i haven't seen people complain about that

[04:15:05.0000] <Hixie>
that's interesting

[04:15:06.0000] <Hixie>
i'd love to read more

[04:15:07.0000] <zcorpan_>
s/people/wysiwyg tool authors/

[04:16:00.0000] <zcorpan_>
only over IM

[04:16:01.0000] <zcorpan_>
in swedish

[04:16:02.0000] <Hixie>
heh ok

[04:16:03.0000] <Hixie>
well changing these things is very risky and expensive

[04:16:04.0000] <Hixie>
but we'll see

[04:16:05.0000] <Hixie>
first though, i shall sleep

[04:16:06.0000] <Hixie>
nn

[04:16:07.0000] <zcorpan_>
nn

[04:16:08.0000] <hsivonen>
nn

[04:18:00.0000] <annevk>
hmm

[04:18:01.0000] <annevk>
handling <!-- in CDATA requires either rearchitecture or hooking into the tree construction stage

[04:19:00.0000] <hsivonen>
annevk: huh. WFM in the tokenizer

[04:19:01.0000] <annevk>
and I don't have a clear plan for the rearchitecture either

[04:19:02.0000] <annevk>
hsivonen, does your tokenizer have knowledge of tag names?

[04:19:03.0000] <hsivonen>
annevk: it knows about void elements

[04:19:04.0000] <zcorpan_>
"The location attribute of the HTMLDocument interface must return the Location object for that Document object." -- i don't know how to test this

[04:22:00.0000] <annevk>
hsivonen, is your impl online somewhere?

[04:31:00.0000] <hsivonen>
annevk: not yet. I had emailed cvsdude support about it. they just emailed my that I have to ask fantasai, so I emailed her to flip the switch

[04:32:00.0000] <hsivonen>
annevk: If you want it now, I can upload a .zip somewhere

[04:32:01.0000] <hsivonen>
s/my/me/

[04:33:00.0000] <annevk>
I can wait I suppose

[04:33:01.0000] <annevk>
there are some other changes I want to make

[04:33:02.0000] <hsivonen>
creating a dump now

[04:34:00.0000] <rubys>
anybody have plans to fix the tests that hsivonen just checked in?

[04:34:01.0000] <hsivonen>
rubys: fix the tests or fix the impl to pass the tests?

[04:34:02.0000] <annevk>
yes, but I'm not sure how

[04:34:03.0000] <annevk>
(talking about fixing the impl here)

[04:35:00.0000] <rubys>
hsivonen: I'm just trying to figure out whether this will be fixed shortly, or if these tests should be added to the todo list.

[04:36:00.0000] <annevk>
If someone can give me a plan for how to do it I'll fix the Python code

[04:36:01.0000] <annevk>
until that happens it's prolly TODO work

[04:36:02.0000] <hsivonen>
annevk: http://hsivonen.iki.fi/htmlparser-dump.zip

[04:36:03.0000] <hsivonen>
annevk: look in nu.validator.*

[04:36:04.0000] <hsivonen>
annevk: fi.iki.* is legacy

[04:37:00.0000] <hsivonen>
annevk: the impl should be in sync with June 17th spec for everything except entities which is in sync with June 12th

[04:41:00.0000] <hsivonen>
annevk: see the last lines of read() as well as dataState()

[04:45:00.0000] <annevk>
HTML4 errors, nice

[04:46:00.0000] <hsivonen>
annevk: as for the plan, I suggest you do what I'm doing, but you need to figure which one of Python's data structures is the most effient one for that kind of low level stuff

[04:46:01.0000] <hsivonen>
/me guesses either list or string

[04:48:00.0000] <annevk>
the problem is getting the last set of characters

[04:49:00.0000] <annevk>
getting this to work fast is another issue...

[04:49:01.0000] <annevk>
for instance, since < triggers closetagopen state that will emit a character '<' on its own

[04:49:02.0000] <annevk>
which is only accessible from the tree construction stage

[04:50:00.0000] <hsivonen>
annevk: can't whatever you use to read the next char put the char into a four-slot ring buffer?

[04:51:00.0000] <annevk>
just for the data state?

[04:51:01.0000] <annevk>
that makes some sense

[04:51:02.0000] <hsivonen>
annevk: don't you have an equivalent for my read()?

[04:51:03.0000] <annevk>
I do

[04:51:04.0000] <annevk>
so that would actually make it fairly trivial :)

[04:52:00.0000] <annevk>
I think...

[04:54:00.0000] <hsivonen>
            if (contentModelFlag != ContentModelFlag.PCDATA) {

[04:54:01.0000] <hsivonen>
                prevFourPtr++;

[04:54:02.0000] <hsivonen>
                prevFourPtr %= 4;

[04:54:03.0000] <hsivonen>
                prevFour[prevFourPtr] = c;

[04:54:04.0000] <hsivonen>
            }

[04:54:05.0000] <hsivonen>
            return c;

[04:55:00.0000] <hsivonen>
where the if may be a premature optimization

[04:56:00.0000] <rubys>
in python/ruby you do just as well with push and pop(0)

[04:57:00.0000] <hsivonen>
rubys: ok. I'm not familiar enough with the performance characteristics of python/ruby date structures for this kind of thing

[05:15:00.0000] <annevk>
hsivonen, do you just do that in the dataState?

[05:15:01.0000] <annevk>
/me wonders if it covers <!</-- well enough

[05:16:00.0000] <hsivonen>
annevk: didn't Hixie spec it for the data state only?

[05:17:00.0000] <hsivonen>
annevk: read() updates the ring buffer from underneath the states

[05:20:00.0000] <annevk>
ah ok, that clarifies it

[05:21:00.0000] <hsivonen>
it's crazy how long the read() method needs to be in order to get all the right things done

[05:27:00.0000] <annevk>
our read method is on the iput stream object

[05:29:00.0000] <hsivonen>
for efficient SAX character data reporting, the tokenizer in Java needs to have access to its buffer 

[06:10:00.0000] <annevk>
you actually only need to look at the last three characters, no?

[06:21:00.0000] <zcorpan_>
"The href attribute returns the address of the page represented by the associated Document object, as an absolute IRI reference." -- this means that both percent-encoded and not percent-encoded are ok, right?

[06:24:00.0000] <annevk>
prolly

[06:42:00.0000] <annevk>
reserializing this document gets ugly: <script><!--

[06:42:01.0000] <hsivonen>
annevk: yeah, the current character has already been seen, so it is sufficient to examine the three previous ones

[06:49:00.0000] <annevk>
hmm

[06:49:01.0000] <annevk>
it's sort of working but I'm hitting weird bugs I can't figure out

[07:15:00.0000] <annevk>
hah, I think I nailed it

[07:15:01.0000] <annevk>
running tests it doesn't seem slower so far

[07:16:00.0000] <annevk>
time to update the tests

[07:31:00.0000] <annevk>
hsivonen, one of your tests has a bug

[07:32:00.0000] <annevk>
hmm

[07:33:00.0000] <hsivonen>
annevk: oh. which one?

[07:33:01.0000] <annevk>
foo<!--></bar><!-->baz</bar>

[07:33:02.0000] <annevk>
<!--> is either a single comment or the start of one

[07:34:00.0000] <annevk>
it's certainly not character data

[07:34:01.0000] <hsivonen>
annevk: why not?

[07:34:02.0000] <annevk>
after the first </bar> is emitted you switch to PCDATA

[07:35:00.0000] <annevk>
we do at least, I suppose that could differ per implementation

[07:36:00.0000] <hsivonen>
oh, right. the latter one

[07:36:01.0000] <annevk>
yeah, the second

[07:36:02.0000] <zcorpan_>
annevk: <!--> can be the start of a comment?

[07:36:03.0000] <annevk>
it also says "end tag surrounded"

[07:36:04.0000] <annevk>
zcorpan_, that was previously the case

[07:36:05.0000] <zcorpan_>
ah

[07:37:00.0000] <annevk>
hsivonen, that should also be changed I suppose

[07:37:01.0000] <hsivonen>
I start to suspect my test harness or impl is broken

[07:38:00.0000] <hsivonen>
brokenness with harness

[07:38:01.0000] <hsivonen>
/me blushes

[07:39:00.0000] <hsivonen>
my impl is totally b0rked, too

[07:47:00.0000] <hsivonen>
my harness was so b0rked it isn't even funny

[07:49:00.0000] <annevk>
another advantage of multiple implementations

[07:57:00.0000] <annevk>
our test coverage is pretty good btw

[07:57:01.0000] <annevk>
each change I make triggers at least one error in the testsuite

[07:57:02.0000] <annevk>
I usually add some regression tests while I'm at it

[08:04:00.0000] <hsivonen>
annevk: has the handling of <!--> in PCDATA changed since June 17th?

[08:04:01.0000] <annevk>
yes

[08:04:02.0000] <annevk>
there are two new comment states to handle <!--> and <!---> as near-empty incorrect comments

[08:04:03.0000] <hsivonen>
argh

[08:05:00.0000] <hsivonen>
I guess I have to go diffing the spec again

[08:05:01.0000] <annevk>
you misunderstand, this is a good thing :)

[08:05:02.0000] <hsivonen>
sure

[08:06:00.0000] <hsivonen>
annevk: thanks

[08:08:00.0000] <annevk>
I think I'll implement that now and see what breaks

[08:30:00.0000] <annevk>
hsivonen, I checked in basic <!--> and <!---> tokenizer tests

[08:34:00.0000] <rubys>
annevk: I'm seeing two failures w/python, is that what you are seeing?

[08:35:00.0000] <annevk>
I have three

[08:35:01.0000] <annevk>
I suspect one of them is just something on my side

[08:35:02.0000] <annevk>
There's one failure in escapeFlag, but that's because the testcase has to be fixed

[08:35:03.0000] <rubys>
do a svn up... you might not have t.broyer's fix

[08:35:04.0000] <annevk>
and there's a failure with respect to newlines

[08:35:05.0000] <annevk>
I've no idea how to fix that

[08:36:00.0000] <annevk>
I got his fixes

[08:36:01.0000] <rubys>
when the code stabilizes, I'll take a look at test_newlines

[08:40:00.0000] <rubys>
... which I guess is now (down to one failure)

[08:41:00.0000] <annevk>
yeah, for the moment

[08:47:00.0000] <rubys>
fixed

[08:52:00.0000] <annevk>
cool

[08:54:00.0000] <rubys>
planning to break more stuff?  :-)  Or is it safe to try to port these changes to Ruby now?

[08:56:00.0000] <annevk>
heh, I think I'll stop doing html5lib for the rest of the day

[09:00:00.0000] <annevk>
things we need to do at some point:

[09:00:01.0000] <annevk>
* fix the new innerHTML stuff (adding a newline for <pre> and <textarea>)

[09:00:02.0000] <annevk>
* fix <isindex>

[09:00:03.0000] <annevk>
* implement almost standards mode

[09:00:04.0000] <annevk>
* <p></body>

[09:01:00.0000] <rubys>
"almost standards mode" doesn't apply to fragments, does it?

[09:02:00.0000] <annevk>
currently quirks mode and almost standards mode don't affect parsing at all

[09:02:01.0000] <annevk>
they're just determined during tree construction

[09:02:02.0000] <rubys>
ah, gotcha

[09:04:00.0000] <rubys>
why did you comment out #import hotshot, hotshot.stats in mockParser?

[09:05:00.0000] <annevk>
oh, that happened on accident I think

[09:05:01.0000] <annevk>
I don't have hotshot here and wanted to play with the other parts

[09:05:02.0000] <rubys>
ok, I'll include that in my next commit.

[09:06:00.0000] <rubys>
I'll move the import down to where it is needed

[10:28:00.0000] <mitsuhiko>
is there lxml support for html5lib around somewhere?

[10:28:01.0000] <mitsuhiko>
i want xpath ;)

[10:43:00.0000] <rubys>
libxml2 is supported in python html5lib

[10:57:00.0000] <mitsuhiko>
rubys: really?

[10:57:01.0000] <mitsuhiko>
i can't find it somehow

[11:04:00.0000] <Philip`>
mitsuhiko: Are you looking in the 0.9 release rather than the SVN version?

[11:05:00.0000] <mitsuhiko>
Philip`: no. svn version

[11:11:00.0000] <Philip`>
mitsuhiko: http://html5lib.googlecode.com/svn/trunk/python/src/treebuilders/__init__.py - looks like it needs etree with implementation=lxml.etree

[11:11:01.0000] <mitsuhiko>
ah

[11:12:00.0000] <Philip`>
(I've not tried using it myself, though)

[12:03:00.0000] <Jero>
does the <dialog> element also apply to comments on a weblog?

[12:34:00.0000] <jgraham>
mitsuhiko: Did you get it working?

[12:34:01.0000] <mitsuhiko>
jgraham: i haven't further tried because i found out that lxml is not exactly what i need

[12:35:00.0000] <mitsuhiko>
basically what i want is a simple tree i push to plugins which then manipulate it, i pickle it afterwards and render on request

[12:36:00.0000] <jgraham>
Does lxml not fulfil that use case

[12:36:01.0000] <jgraham>
/me wonders if picking wouldn't work

[12:36:02.0000] <jgraham>
pickling even

[12:36:03.0000] <mitsuhiko>
jgraham: it's out of the scope because it's not a python library

[12:36:04.0000] <mitsuhiko>
(unfortunately)

[12:37:00.0000] <jgraham>
Oh, you need to work with the python stdlib? 

[12:37:01.0000] <mitsuhiko>
no, just not binary stuff

[12:37:02.0000] <jgraham>
Does that not rule out XPath?

[12:37:03.0000] <mitsuhiko>
jgraham: indeed. that's why i found a different solution

[12:38:00.0000] <jgraham>
What are you using?

[12:39:00.0000] <mitsuhiko>
i have a minimal Node class with a filter function that uses a very simple query "language" that is easily parsable

[12:39:01.0000] <mitsuhiko>
(in theory performance doesn't matter because i put the pickled stuff into the database but i want to keep it simple)

[12:40:00.0000] <mitsuhiko>
but the html5 library is really nice :D

[13:00:00.0000] <annevk>
Jero, I'd suggest e-mailing the list; that is either a good example for good usage or bad usage

[13:01:00.0000] <annevk>
Jero, personally I think it would be incorrect, <article> is for marking up comments iirc

[13:01:01.0000] <annevk>
Jero, personally I think it would be incorrect, <article> is for marking up comments iirc

[13:01:02.0000] <Jero>
annevk: yeah, I saw that too, but <dialog> also seemed like a good candidate. I'll email the list, thanks

[13:02:00.0000] <annevk>
krijnh, pointer?

[13:02:01.0000] <annevk>
hmm

[13:21:00.0000] <annevk>
http://pkarl.com/notebook/if-you-dont-approve-of-html5-then-youre-a-communist/

[13:22:00.0000] <Lfe>
got to love how blogs has improved page titles :)

[13:22:01.0000] <annevk>
http://www.burningbird.net/technology/marathon-20/

[13:40:00.0000] <Jero>
does anyone know anything about the http://php-html5lib.dashslot.net/trac project?

[14:11:00.0000] <Philip`>
/me wonders why he always ends up writing far more than he intends to

[14:12:00.0000] <Hixie>
just go back and remove sentences afterwards :-)

[14:12:01.0000] <Hixie>
i often write e-mails twice as long as the ones i eventually send out

[14:12:02.0000] <Hixie>
just have to apply a razor

[14:23:00.0000] <Hixie>
annevk: maybe try "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent."

[14:25:00.0000] <annevk>
christ

[14:25:01.0000] <annevk>
got to love comments like that

[14:26:00.0000] <Hixie>
yeah

[14:26:01.0000] <Hixie>
the text above is what html5 says

[14:26:02.0000] <Hixie>
fwiw

[14:26:03.0000] <annevk>
k

[14:26:04.0000] <Dashiva>
How about just combining them? "MUST follow either the algorithm below or an algorithm giving identical results"

[14:27:00.0000] <gsnedders>
I prefer the current text over that

[14:27:01.0000] <othermaciej>
I think instead of changing the conformance requirements for every algorithm, the text that says equivalent algorithms are ok could be made more explicit

[14:28:00.0000] <annevk>
I think that's what Hixie suggested above

[14:28:01.0000] <Hixie>
Dashiva: there's like a thousand occurences of the text "must follow these steps:" in html5, i'm not replacing every single one with weasle-wording

[14:29:00.0000] <othermaciej>
I did not see his text above

[14:29:01.0000] <othermaciej>
I guess I should check the logs

[14:29:02.0000] <Hixie>
22:31 <         Hixie>|annevk: maybe try "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent."

[14:29:03.0000] <Hixie>
(it's what's in html5)

[14:30:00.0000] <othermaciej>
that sounds pretty good

[14:32:00.0000] <Hixie>
it wouldn't satisfy people who are looking for problems where there are none, sadly

[14:37:00.0000] <othermaciej>
if you wanted to be even more explicit you could say "Wherever this user agent says that a user agent must follow a particular algorithm or sequence of stops, user agents may use any algorithm that has the same results."

[14:37:01.0000] <othermaciej>
just so no one imagines a must / may conflict

[14:38:00.0000] <Dashiva>
That's a good one

[14:38:01.0000] <othermaciej>
s/this user agent/this specification/

[14:52:00.0000] <annevk>
bjoern disagrees...

[14:52:01.0000] <annevk>
I think I'll call it a day

[14:52:02.0000] <annevk>
to boring to worry about now

[14:53:00.0000] <Hixie>
hear hear

[15:04:00.0000] <Hixie>
hey, anyone have a link to that summary of why versioning is bad? i think it was either henri or lachy that wrote it

[15:04:01.0000] <Hixie>
can't find it anywhere

[15:07:00.0000] <gavin>
http://lists.w3.org/Archives/Public/public-html/2007Apr/0858.html , maybe?

[15:07:01.0000] <gavin>
I recall one from hsivonen that I can't find, either

[15:09:00.0000] <Hixie>
yeah that's all i could find too (arguments against IE's plan, rather than versioning in general)

[15:09:01.0000] <gavin>
this is going to bother me now

[15:10:00.0000] <bewest>
Hixie: some people interpret the versioning issue to imply that since html(5) will have no versioning in the doctype, that therefore every feature of html5 is perfect and won't need revising.

[15:11:00.0000] <Hixie>
yeah

[15:12:00.0000] <bewest>
at least, that is the complaint in #web

[15:12:01.0000] <bewest>
among others.

[15:14:00.0000] <hasather>
Hixie: http://lists.w3.org/Archives/Public/public-html/2007JanMar/0433.html?

[15:15:00.0000] <Hixie>
hm yes

[15:15:01.0000] <Hixie>
i think that was it!

[15:15:02.0000] <Hixie>
thanks!

[15:16:00.0000] <gavin>
ah, good

[15:17:00.0000] <hasather>
Hixie: there's also http://lists.w3.org/Archives/Public/public-html/2007Apr/0279

[15:18:00.0000] <Hixie>
i think he sent one to www-tag at some point, too

[15:19:00.0000] <hasather>
found those via zcorpan's del.icio.us :)

[15:19:01.0000] <Hixie>
dbaron's is pretty good too, yeah

[15:22:00.0000] <Hixie>
/me sends his mail to www-archive

[15:25:00.0000] <hendry>
are there any specs for spreadsheet type support in html?

[15:25:01.0000] <hendry>
there's mathml, in know, but is that it?

[15:25:02.0000] <Hixie>
define "spreadsheet type support"?

[15:26:00.0000] <Hixie>
http://spreadsheet.google.com/ is all HTML

[15:26:01.0000] <hendry>
functions and stuff I guess

[15:26:02.0000] <hendry>
:)

[15:26:03.0000] <bewest>
and there's an API for the spreadsheets stuff

[15:26:04.0000] <hendry>
though that's a representation?

[15:33:00.0000] <othermaciej>
annevk, Hixie: I think to be really and truly proper, it is a bit nicer to explicitly say "as if" at each site mentioning an algorithm, but a blanket clarification in the conformance section is also fine

[15:33:01.0000] <othermaciej>
bjoern's suggested alternative is just crazy

[15:40:00.0000] <Hixie>
the html5 spec is hard enough to read already without having pointless "as if"s all over the place

[15:40:01.0000] <Hixie>
everyone to whom it actually matters is completely aware that it's "as if" anyway

[15:41:00.0000] <gsnedders>
/me just wants to say "as if it's hard to read!"

[15:47:00.0000] <hsivonen>
en-GB-x-hixie-x-valleygirl

[15:48:00.0000] <gsnedders>
as if.

[15:53:00.0000] <Philip`>
It's annoyingly hard to concentrate when there's two simultaneous firework displays outside

[16:08:00.0000] <Hixie>
wow

[16:08:01.0000] <Hixie>
Opera actually supports <![CDATA[ ]]> in text/html

[16:08:02.0000] <Hixie>
it creates an actual #cdata-section

[16:08:03.0000] <Hixie>
i'm glad i added support for #cdata-sections to the live DOM viewer now

[16:08:04.0000] <Hixie>
i really didn't think that code would ever get hit

[16:16:00.0000] <Philip`>
Hixie: It seems to be implemented pretty weirdly - it dislikes having either [ or ] inside the CDATA section, which doesn't make much sense to me...

[16:17:00.0000] <Philip`>
Oh, actually it just dislikes it when the number of [ is not equal to the number of ]

[16:23:00.0000] <jgraham>
Philip`: Where are you with all the fireworks?

[16:23:01.0000] <Philip`>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21%5BCDATA%5B%20%5B%5B%5D%5D%3E%20%5D%5D%3E - ah, it looks very much like it has a count of how deeply nested it is, and if sees a > after the nesting level has got back to 0 then it exits CDATA mode

[16:24:00.0000] <Philip`>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21%5BCDATA%5B%5Dxyzw%5Dabcd%3E - and once it's seen the > at nesting-level 0, it deletes the last two characters (regardless of what they were)

[16:26:00.0000] <Philip`>
...which all seems like a totally bogus thing to do

[16:27:00.0000] <Hixie>
it drops everything between the last ] and the > as far as i can tell

[16:27:01.0000] <Hixie>
oh no

[16:27:02.0000] <Hixie>
you're right

[16:29:00.0000] <Hixie>
has to be exactly the string <![CDATA[, too

[16:29:01.0000] <Hixie>
that's so funny

[16:29:02.0000] <Hixie>
i wonder how this can be abused

[16:33:00.0000] <Philip`>
Looks like it parses exactly the same (requiring nested brackets and everything) if it just has <![ but only creates the cdata-section if it's followed by cdata[

[16:33:01.0000] <Hixie>
huh

[16:33:02.0000] <Hixie>
weirder and weirder

[16:35:00.0000] <Philip`>
Oh, no, it does it you have <!] too (then the nesting level starts at -1 so you have to do <!][> to get out of it)

[16:36:00.0000] <Philip`>
+if

[16:36:01.0000] <Hixie>
lol

[16:36:02.0000] <Hixie>
nic8e

[16:36:03.0000] <Hixie>
nice

[16:36:04.0000] <Hixie>
how about <!--, does that still have the counting?

[16:46:00.0000] <Philip`>
jgraham: In Cambridge (where it looks like most of the people are quite happy to have stopped working for the next few months :-) )

[16:47:00.0000] <jgraham>
Snap :)

[16:47:01.0000] <Philip`>
Hixie: I can't see Opera doing anything other than waiting until it sees --> after it's got <!--

[16:48:00.0000] <Philip`>
though it does do the []-counting if you just have <!- followed by anything except -

[16:51:00.0000] <Philip`>
jgraham: Are you somewhere near the centre of Cambridge?

[16:52:00.0000] <jgraham>
Yeah

[16:52:01.0000] <Hixie>
Philip`: interesting

[16:53:00.0000] <Philip`>
/me was perfectly located to see the fireworks as long as he opened his window quite wide and let all the rain in

[16:54:00.0000] <jgraham>
My view is usually blocked so I didn't try very hard

[16:58:00.0000] <Hixie>
only 122 more e-mails in my html-parsing-rules folder

[16:58:01.0000] <Hixie>
(not counting the -encoding subfolder, etc)

[16:58:02.0000] <bewest>
oo othat reminds me to send some feedback from a coworker


2007-06-20
[17:04:00.0000] <Philip`>
http://lachy.id.au/log/2005/05/script-comments says "the only user agent I know of the supports the CDATA section for HTML documents is the new Opera 8", so it sounds like it wasn't added before v8. (I have no idea why they ever added it, particularly with such an intriguing implementation...)

[17:04:01.0000] <Hixie>
yeah

[17:04:02.0000] <Hixie>
well

[17:04:03.0000] <Hixie>
no comment

[17:05:00.0000] <Hixie>
i love how zcorpan reported the same issue several times (probably without realising it)

[18:00:00.0000] <Hixie>
ok i'm sure what i just did just about broke everything in the spec

[18:00:01.0000] <Hixie>
so, please let me know if you find issues with those checkins...

[18:03:00.0000] <jruderman>
Hixie: did you just set the spec on fire?

[18:04:00.0000] <Hixie>
i abstracted out innerHTML's getter and setter to generic algorithms

[18:12:00.0000] <Philip`>
Looks like the innerHTML link in item 3 a bit below http://www.whatwg.org/specs/web-apps/current-work/#innerhtml1 should link to innerhtml1 (to be consistent with all the others in that section) instead of innerhtml0. Or maybe all those should link to innerhtml0 instead, or something.

[18:13:00.0000] <Hixie>
oops

[18:14:00.0000] <Hixie>
will dix

[18:14:01.0000] <Hixie>
f6ix

[18:14:02.0000] <Hixie>
fix

[18:33:00.0000] <Philip`>
Ooh, excellent, I get non-deterministic behaviour when drawing a couple of arcs and rectangles in Opera

[18:35:00.0000] <Hixie>
uri?

[18:36:00.0000] <Philip`>
Just trying to make a sensible test case now

[18:42:00.0000] <Hixie>
/me giggles

[18:42:01.0000] <Hixie>
one of my colleagues introduced me to one of our interns, saying i was a standards guru

[18:42:02.0000] <Hixie>
the intern asked if i knew about the whatwg

[18:43:00.0000] <bewest>
hehe

[18:43:01.0000] <bewest>
do you pronounce whatwg?

[18:43:02.0000] <bewest>
or do you say W-H-A....

[18:44:00.0000] <Hixie>
i pronounce it "whatwuhjee"

[18:44:01.0000] <Hixie>
and i guess that's canonical since i came up with it

[18:44:02.0000] <Hixie>
when i'm talking more formally i call it the "What double you gee"

[18:45:00.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/operanondet.html - that's running the same code lots of times, and I get a random selection of about four renderings (of which two are quite rare)

[18:45:01.0000] <bewest>
I usually say whatwahguhdfm.....

[18:45:02.0000] <Philip`>
...in Opera 9.21 on Windows and Linux

[18:45:03.0000] <Philip`>
(Turns out it doesn't actually need arcs at all)

[18:46:00.0000] <Hixie>
all look the same to me on 9.00

[18:46:01.0000] <Hixie>
(windows)

[18:46:02.0000] <Hixie>
bewest: whatwahguhdfm?

[18:46:03.0000] <Philip`>
Does it stay the same if you reload the page a few times?

[18:46:04.0000] <Hixie>
(wish it was easier to keep up to date with opera, sheesh)

[18:46:05.0000] <Hixie>
seems yes

[18:47:00.0000] <bewest>
Hixie: yes, and then my voice kind of trails off at the end, and then I resume what I was saying.

[18:47:01.0000] <Hixie>
heh

[18:48:00.0000] <Hixie>
i recommend "whatwuhjee"

[18:48:01.0000] <bewest>
yeah, seems better.

[18:48:02.0000] <Hixie>
Philip`: wow, yeah, opera 9.21 is all over the place

[18:51:00.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/operanondet.png - that has all the four renderings I've noticed

[18:59:00.0000] <Hixie>
funky

[19:01:00.0000] <Hixie>
ok, renamed "innerHTML case" to "fragment case"

[19:02:00.0000] <Hixie>
wow, the last csswg meeting had all of four people on the call

[19:35:00.0000] <Hixie>
http://bugs.webkit.org/show_bug.cgi?id=12740 is heartwarming

[19:35:01.0000] <othermaciej>
like heartburn?

[19:36:00.0000] <Hixie>
no

[19:36:01.0000] <Hixie>
like a hug :-P

[19:37:00.0000] <othermaciej>
ah yes, that was a nice fix

[19:37:01.0000] <othermaciej>
interop problem solved by following spec

[19:40:00.0000] <karlUshi>
othermaciej: which part of the spec?

[19:40:01.0000] <othermaciej>
Hixie: part of the HTML5 parsing algorithm

[19:40:02.0000] <Hixie>
i assume that was to karl

[19:40:03.0000] <karlUshi>
;)

[19:40:04.0000] <Hixie>
since i looked at the bug and therefore knew :-)

[19:41:00.0000] <othermaciej>
er, yeah

[19:41:01.0000] <othermaciej>
karlUshi: meant that for you

[19:41:02.0000] <karlUshi>
a specific part of the parsing algorithm

[19:42:00.0000] <karlUshi>
I have an idea to explain people why html5 parsing rules are important.

[19:42:01.0000] <karlUshi>
I think it is a good example

[19:45:00.0000] <karlUshi>
http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#in-table

[19:46:00.0000] <karlUshi>
it seems to be it

[19:51:00.0000] <Philip`>
karlUshi: Looks like the "A start tag whose tag name is "table"" case in there, in particular

[20:30:00.0000] <Lachy>
Hixie, yt?

[20:51:00.0000] <Hixie>
yo

[20:52:00.0000] <Hixie>
Lachy?

[20:56:00.0000] <Lachy>
hey

[20:56:01.0000] <Lachy>
regarding Selectors API, Jonas' last message on member-webapi and http://lists.w3.org/Archives/Public/public-webapi/2006Sep/0100.html

[20:57:00.0000] <Lachy>
I'm wondering if you could help me understand what the issue is - there doesn't seem to be one

[20:57:01.0000] <Hixie>
which part?

[20:57:02.0000] <Lachy>
in particular, the scoped selectors part.

[20:58:00.0000] <Lachy>
AFAIK, scoped selectors don't exist, so how can I deal with them?

[20:58:01.0000] <Hixie>
i don't see the problem either

[21:00:00.0000] <Lachy>
also, regarding the :root issue, it seems to me that it would only ever match the root of the document, not the root of a subtree, so I don't see what the problem is there either

[21:00:01.0000] <Hixie>
i agree

[21:00:02.0000] <Hixie>
/me wonders exactly what chaals meant in reply to the f2f questionnaire

[21:00:03.0000] <Lachy>
cool.  I'll just reply and explain why it's not an issue.

[21:01:00.0000] <Hixie>
i can't tell if he thinks i'm wrong in saying the telecon was a waste of time or what

[21:01:01.0000] <Hixie>
guess i'll have to catch him online at some point

[21:01:02.0000] <Lachy>
which f2f questionaire?

[21:01:03.0000] <Hixie>
http://www.w3.org/2002/09/wbs/40318/mtgmv/

[21:02:00.0000] <Hixie>
given that only 13 people replied, and at least one of them only replied because i asked them about it, i'm starting to wonder if anyone actually reads public-html these days

[21:02:01.0000] <Lachy>
I haven't paid much attention to it recently.  I marked about ~300 messages as read a few days ago cause I couldn't be bothered

[21:03:00.0000] <Lachy>
I didn't even know they were going to have an f2f

[21:03:01.0000] <Hixie>
heh

[21:05:00.0000] <Hixie>
right, going home

[21:05:01.0000] <Hixie>
bbl

[21:05:02.0000] <Lachy>
ok, cya

[21:08:00.0000] <Philip`>
Hmm, commit-watchers seems to still be randomly ignoring some commits (823, 839, 898, 908, 912, 932, 934)

[23:47:00.0000] <Hixie>
Philip`: weird

[23:51:00.0000] <Lachy_>
what do people think of selectOne/selectAll as the resolution to the selectors api naming debate? (I'm currently going through ~300 emails reviewing the arguments)

[23:59:00.0000] <Hixie>
sounds good to me, but i think the reason anne didn't pick those is that they are either too similar or actually clash with the xpath functions that IE supports

[00:00:00.0000] <Lachy_>
yeah, I did the research on that.  XPath uses selectSingleNode/selectNodes

[00:00:01.0000] <Lachy_>
.select() is out because it's already used in <textarea> and <input type=text> APIs

[00:01:00.0000] <Lachy_>
the other alternative I'm considering is choose*()

[00:02:00.0000] <Hixie>
i prefer select

[00:02:01.0000] <Lachy_>
me too

[00:02:02.0000] <Hixie>
/me finds a page that renders differently in IE than in other browsers because <span> is not considered a formatting element

[00:02:03.0000] <Lachy_>
I still have about 150 emails to get through.  Then I'll finish summarising the arguments and send the results to the list

[00:06:00.0000] <Hixie>
and then you'll be told you're being biased, and will have to ignore about 30% of the people, who will raise formal objections... welcome to the editor's job :-)

[00:07:00.0000] <Lachy_>
yeah, why do you think I've been avoiding the issue for so long? :-)

[00:07:01.0000] <Lachy_>
at least the CSS WG resolved the case sesitivity issue for me earlier today :-)

[00:11:00.0000] <Hixie>
yeah

[00:11:01.0000] <Hixie>
impressive

[00:12:00.0000] <Lachy_>
are you going to consider fixing the issue in XBL to make the prefixes case senstive now, or just leave it as is?

[00:12:01.0000] <Hixie>
i'll fix it in due course

[00:12:02.0000] <Lachy_>
cool

[00:19:00.0000] <Hixie>
annevk: yt?

[00:36:00.0000] <Hixie>
http://news.com.com/8301-10784_3-9731230-7.html?part=rss&subj=news&tag=2547-1_3-0-5

[00:36:01.0000] <Hixie>
seriously, they're getting worse

[00:36:02.0000] <Hixie>
when will they learn?

[00:36:03.0000] <Lachy_>
yeah, I noticed that earlier.  I just laughed

[00:48:00.0000] <Lachy_>
oh dear! Flash CS3 apparently uses document.selectAll() already :-(

[00:48:01.0000] <karlUshi>
Hixie: you mean journalists… indeed :p Tempest in a tea post

[00:49:00.0000] <karlUshi>
slashdot is more interesting on the issue

[00:49:01.0000] <othermaciej>
Lachy_: for what?

[00:49:02.0000] <othermaciej>
what does it expect selectAll to do?

[00:50:00.0000] <Lachy_>
I'm getting the link...

[00:50:01.0000] <Lachy_>
http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00003989.html

[00:51:00.0000] <Lachy_>
it apparently seems to do text selection, though I'm not totally sure

[00:51:01.0000] <othermaciej>
so wait, Flash extends the Document object?

[00:51:02.0000] <othermaciej>
/me is confused

[00:52:00.0000] <othermaciej>
"The Document object represents the Stage. That is, only FLA files are considered documents."

[00:52:01.0000] <Lachy_>
well, it calls it a DOM, but it doesn't seem to be related to the W3C DOM

[00:52:02.0000] <othermaciej>
none of that stuff is in any way related to the DOM as we know it, as far as I can tell

[00:53:00.0000] <othermaciej>
Lachy_: the article about the w3c is hilarious

[00:55:00.0000] <zcorpan_>
can anyone access http://forums.whatwg.org/ ?

[00:55:01.0000] <Lachy_>
zcorpan_, no

[01:02:00.0000] <zcorpan_>
ok

[01:03:00.0000] <Hixie>
server is rebooting

[01:03:01.0000] <MikeSmith>
great to see that Declan McCullagh at it again

[01:35:00.0000] <zcorpan_>
does it matter whether something is implemented in the tokenizer or the parser?

[01:37:00.0000] <hsivonen>
zcorpan_: if you want to use tokenizer-specific unit tests, yes.

[01:37:01.0000] <hsivonen>
zcorpan_: matter for whom?

[01:38:00.0000] <hsivonen>
zcorpan_: also, in the case of Java (or C#, I presume), upper or lower casing stuff in the tokenizer is a bit cheaper than leaving it to the tree builder

[01:39:00.0000] <hsivonen>
(languages that have both char[] and immutable String)

[01:39:01.0000] <hsivonen>
scratch that--the statement makes assumptions about the interface between the tokenizer and the tree builder

[01:41:00.0000] <zcorpan_>
hsivonen: whether it matters for spec conformance

[01:42:00.0000] <hsivonen>
zcorpan_: it may matter to the order of parse errors

[01:42:01.0000] <hsivonen>
zcorpan_: I'd expect

[01:42:02.0000] <othermaciej>
does the spec require a particular order for parse errors?

[01:43:00.0000] <hsivonen>
othermaciej: IIRC, there was some language tied to "first"

[01:43:01.0000] <zcorpan_>
e.g., if something is more performant to implement in the parser for implementor A and more performant to implement in the tokenizer for implementor B, and the end result is the same, then i don't see a good reason to make one implementation non-conforming

[01:44:00.0000] <hsivonen>
zcorpan_: agreed

[01:45:00.0000] <hsivonen>
othermaciej: ah. not relevant. it was not the first as defined by the algorithm but the first for which the impl takes special action

[01:46:00.0000] <hsivonen>
"The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below."

[01:47:00.0000] <zcorpan_>
could be phrased as s/the first/any/

[01:49:00.0000] <hsivonen>
fwiw, I'll probably make following that rule optional

[01:49:01.0000] <hsivonen>
(i.e. allow the user of the parser to enable non-conforming coercion to XML 1.0 infoset)

[01:50:00.0000] <hsivonen>
in the parser library that is--not in the conformance checker

[02:13:00.0000] <hsivonen>
hmm. the state transitions between the new comment states aren't nice

[02:13:01.0000] <hsivonen>
/me wonders if one state with hyphen counting would work

[02:15:00.0000] <zcorpan_>
hmm, writing test cases for .lastModified seems non-trivial

[02:15:01.0000] <zcorpan_>
or not, i can use http headers

[02:18:00.0000] <hsivonen>
it seems to me that it is the easiest to combine the last three comment states and to use a counter

[02:21:00.0000] <zcorpan_>
"The last two digits of the year component of the date." -- shouldn't this be 4 digits?

[02:26:00.0000] <Hixie>
hsivonen: the biggest problem with that is getting the parse errors right

[02:27:00.0000] <hsivonen>
Hixie: "that" being a counter?

[02:27:01.0000] <Hixie>
yeah

[02:27:02.0000] <Hixie>
well, with not using the numerous states i used

[02:28:00.0000] <zcorpan_>
Hixie: was the year component of .lastModified a mistake? should i bug the list about it? (all browsers return the year in 4 digits)

[02:28:01.0000] <Hixie>
why are the states troublesome? because of using a stack-based approach instead of a switch? or?

[02:29:00.0000] <hsivonen>
Hixie: using a stack-based approach and I don't want arbitrary recursion based on input

[02:29:01.0000] <Hixie>
zcorpan_: hm

[02:29:02.0000] <hsivonen>
Hixie: plus the direct transition to comment end state from comment start dash state

[02:30:00.0000] <Hixie>
ah

[02:30:01.0000] <Hixie>
just have a little state machine in your function :-)

[02:30:02.0000] <hsivonen>
Hixie: isn't the counter exactly it?

[02:31:00.0000] <hsivonen>
0: comment 1: end dash 2: end

[02:31:01.0000] <Hixie>
well, if you get the parse errors right

[02:31:02.0000] <Hixie>
<!--> has a parse error, <!----> does not

[02:31:03.0000] <Hixie>
<!---> has a parse error, <!-- ---> has a parse error

[02:32:00.0000] <Hixie>
<!-- --> does not

[02:33:00.0000] <Hixie>
zcorpan_: oops, i'll fix that

[02:33:01.0000] <Hixie>
zcorpan_: no need to report it

[02:33:02.0000] <hsivonen>
Hixie: um. according to the revision of comment start dash state that I am looking at, <!--> does not have a parse error

[02:33:03.0000] <zcorpan_>
Hixie: ok

[02:33:04.0000] <hsivonen>
oop

[02:33:05.0000] <hsivonen>
s

[02:34:00.0000] <hsivonen>
never mind

[02:34:01.0000] <Hixie>
you start in the comment start state, not the comment start dash state

[02:34:02.0000] <hsivonen>
Hixie: I wasn't going to use a counter for the comment start * states

[02:35:00.0000] <Hixie>
ah ok

[02:43:00.0000] <annevk>
Hixie, I am here now

[02:43:01.0000] <Hixie>
sent you mail

[02:43:02.0000] <annevk>
having said that, I haven't checked e-mail so far

[02:43:03.0000] <annevk>
ok

[02:43:04.0000] <hsivonen>
Hixie: considering markup decl open state, how could you ever go through the comment start* states without hitting the '-' cases?

[02:44:00.0000] <hsivonen>
"If the next two characters are both U+002D HYPHEN-MINUS (-) characters, consume those two characters, create a comment token whose data is the empty string, and switch to the comment start state."

[02:44:01.0000] <Hixie>
they're consumed (by the text you just quoted) before you enter that state

[02:46:00.0000] <hsivonen>
ooh! the purpose of those states is very different from what I though

[02:46:01.0000] <hsivonen>
t

[02:47:00.0000] <Hixie>
oh

[02:47:01.0000] <Hixie>
heh :-)

[02:47:02.0000] <hsivonen>
calling them "start" is confusing

[02:48:00.0000] <Hixie>
why?

[02:48:01.0000] <Hixie>
they're at the start

[02:48:02.0000] <hsivonen>
when they actually test for bogus end

[02:48:03.0000] <Hixie>
what should i call them?

[02:48:04.0000] <Hixie>
i don't want to have the tokeniser enter a state with the name "bogus" for quite compliant markup

[02:48:05.0000] <hsivonen>
commentPotentiallyBogusDashOne commentPotentiallyBogusDashTwo

[02:50:00.0000] <annevk>
whoa

[02:50:01.0000] <Hixie>
i don't like names with "bogus" in them that are not bogus :-)

[02:50:02.0000] <Hixie>
"whoa"?

[02:51:00.0000] <hsivonen>
Hixie: only *potentially#

[02:51:01.0000] <Hixie>
oh i understand your proposal

[02:51:02.0000] <Hixie>
i just don't particularly like it :-)

[02:51:03.0000] <Hixie>
i understand how the current text is confusing though

[02:52:00.0000] <hsivonen>
annevk: what was your reading of the purpose of the new states?

[02:52:01.0000] <annevk>
whoa was in response to the new names

[02:52:02.0000] <annevk>
hsivonen, to address parse errors for <!--> and <!--->

[02:53:00.0000] <hsivonen>
annevk: yeah, but was your intuitive reading that <!--> would go through comment start dash?

[02:53:01.0000] <hsivonen>
annevk: am I the only one who is confused?

[02:53:02.0000] <Hixie>
i agree that the current state names are confusing

[02:53:03.0000] <Hixie>
and will look for better names

[02:53:04.0000] <hsivonen>
Hixie: ok thanks

[02:54:00.0000] <Hixie>
on another note, the w3c pubrules checker is retarded

[02:55:00.0000] <annevk>
hsivonen, how does <!--> go through comment start dash? it is emitted during comment start

[03:04:00.0000] <hsivonen>
annevk: it doesn't. that's my point

[03:05:00.0000] <zcorpan_>
Hixie: wow this is interesting. ie takes daylight-saving time into account for .lastModified. firefox doesn't.

[03:06:00.0000] <annevk>
hmm

[03:06:01.0000] <annevk>
I suppose I'm too used to everything after <!-- being the start of the comment

[03:06:02.0000] <zcorpan_>
http://simon.html5.org/test/html/dom/interfaces/HTMLDocument/lastModified/001.php

[03:07:00.0000] <zcorpan_>
in ie, it failed, but when i turned off "automatically adjust daylight-saving time" in windows, the test passed

[03:07:01.0000] <hsivonen>
on a related note: if an HTML5 doc contains <!--a--b-->, what would you like the result of XHTML5 conversion be? (assuming fatal error is not an option)

[03:07:02.0000] <zcorpan_>
in firefox it passed both times

[03:09:00.0000] <hsivonen>
is substituting two EN DASHes in the middle evil and/or confusing? what about a single U+FFFD?

[03:11:00.0000] <annevk>
I think the DOM spec suggested something like "--" -> "- -"

[03:11:01.0000] <hsivonen>
ok

[03:14:00.0000] <annevk>
Hixie, does Google have some secret project that relies on the placement of comments? :)

[03:14:01.0000] <zcorpan_>
"The presence of this character sequence must generate a fatal error during serialization." -- http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1728279322

[03:15:00.0000] <annevk>
I stick with my suggestion

[03:15:01.0000] <annevk>
I believe browsers already support <base> in XHTML

[03:16:00.0000] <hsivonen>
zcorpan_: let's assume I'm going to have an infoset-altering option for everything that the specs say is fatal

[03:17:00.0000] <zcorpan_>
hsivonen: ok. that was the text i found when looking for what annevk referred to ("--" -> "- -")

[03:17:01.0000] <zcorpan_>
(that almost looked like a smiley)

[03:19:00.0000] <zcorpan_>
/me will bug the list about daylight-saving time on .lastModified

[03:19:01.0000] <hsivonen>
the whattf CVS to SVN migration support thread has 14 messages and the transition still isn't done...

[03:19:02.0000] <hsivonen>
not counting my replies

[03:21:00.0000] <Hixie>
annevk: heh, no, i just want whitespace and comments to be in the DOM in the same place they are in the markup

[03:22:00.0000] <hsivonen>
Hixie: that'll be another use of XmlViolationPolicy.ALTER_INFOSET, then

[03:23:00.0000] <Hixie>
which?

[03:23:01.0000] <hsivonen>
Hixie: appending stuff to </head>

[03:23:02.0000] <hsivonen>
to head

[03:23:03.0000] <hsivonen>
after </head> has been seen

[03:24:00.0000] <hsivonen>
or are there those cases still

[03:24:01.0000] <hsivonen>
perhaps I'm just way too confused this morning. I woke up too early

[03:25:00.0000] <Hixie>
heh

[03:26:00.0000] <zcorpan_>
is it possible to get daylight-saving time info from javascript? 

[03:26:01.0000] <hsivonen>
annevk: is your remainin </head> suggestion only about white space and comments?

[03:29:00.0000] <zcorpan_>
iirc, firefox inserts whitespace and comments that appear before <head> in the HEAD, and after </body> in the BODY. and between </head> and <body> in HEAD.

[03:31:00.0000] <annevk>
If we ignore </head> there's no moving around of elements anymore

[03:31:01.0000] <annevk>
a lot less special processing

[03:31:02.0000] <annevk>
and in general a simpler parsing model

[03:32:00.0000] <Hixie>
the complexity involved here is miniscule compared to almost any other part of the spec

[03:35:00.0000] <zcorpan_>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21--before-doctype--%3E%3C%21doctype%20html%3E%3C%21--before-html--%3E%3Chtml%3E%3C%21--before-head--%3E%3Chead%3E%3C/head%3E%3C%21--before-body--%3E%3Cbody%3E%3C/body%3E%3C%21--after-body--%3E%3C/html%3E%3C%21--after-html--%3E

[03:36:00.0000] <annevk>
after body and after html will always be part of body I believe

[03:36:01.0000] <Hixie>
not in html5

[03:37:00.0000] <Hixie>
i need to find a way to handle whitespace, too

[03:37:01.0000] <Hixie>
i can reuse whatever solution i find for <table> whitespace processing

[03:39:00.0000] <hsivonen>
there are way too many pointless edge case differences between html4, html5 and xml 1.0

[03:39:01.0000] <hsivonen>
I don't care about xml 1.1, which is itself pointless

[03:40:00.0000] <hsivonen>
unfortunately, the silliness is mostly due to XML banning arbitrary stuff

[03:40:01.0000] <annevk>
or html5 allowing arbitrary stuff

[03:41:00.0000] <hsivonen>
well, yeah

[03:41:01.0000] <annevk>
then again, html was there first

[03:41:02.0000] <zcorpan_>
the arbitrary stuff in xml was copied from sgml, wasn't it?

[03:42:00.0000] <hsivonen>
zcorpan_: U+FFFE and U+FFFF sure were not

[03:43:00.0000] <zcorpan_>
hsivonen: ok. 

[03:43:01.0000] <hsivonen>
/me wonders who is actually able to use U+FFFF as a sentinel

[03:46:00.0000] <Lachy_>
wow! I just finished reading through every email I have on the naming debate :-)

[03:46:01.0000] <hsivonen>
Lachy_: naming?

[03:46:02.0000] <Lachy_>
selectors api

[03:46:03.0000] <hsivonen>
Lachy_: onwards to XHTML5 then :-)

[03:46:04.0000] <Lachy_>
the debate between matchAll()/getElementBySelector() and dozens of other alternatives

[03:47:00.0000] <zcorpan_>
Lachy_: did you get any wiser? :)

[03:47:01.0000] <Lachy_>
I'm about to send the summary of my research to public-webapi

[03:48:00.0000] <Lachy_>
sadly, I had to give up on selectOne/selectAll idea :-(

[03:48:01.0000] <Lachy_>
I'm considering a few like the following...

[03:48:02.0000] <Lachy_>
selectElement/selectElementList

[03:48:03.0000] <Lachy_>
getElement/getElementList

[03:49:00.0000] <othermaciej>
selectElement would be extremely confusing given selectSingleNode

[03:49:01.0000] <othermaciej>
I would sugget cssQuery / cssQueryAll or cssQueryOne / cssQuery

[03:49:02.0000] <zcorpan_>
Lachy_: was it pointed out that dean edwards' base2 uses matchAll() and matchSingle() to implement the spec?

[03:49:03.0000] <othermaciej>
short and unambiguous

[03:49:04.0000] <Lachy_>
yeah, that's the argument against all the select* alternatives

[03:49:05.0000] <Lachy_>
zcorpan_, yes, I'm aware

[03:50:00.0000] <Hixie>
nn all

[03:50:01.0000] <Lachy_>
cya hixie

[03:50:02.0000] <zcorpan_>
Hixie: nn

[03:50:03.0000] <hsivonen>
nn

[03:51:00.0000] <othermaciej>
I'm not a fan of the getElementBySelector name that was theoretically chosen by the group but never put in the spec

[03:51:01.0000] <othermaciej>
but I also think on further thought that get() / getAll() is a little *too* concise

[03:51:02.0000] <annevk>
the problem with that is chosing a name for the one that matches multiple

[03:52:00.0000] <Lachy_>
if we didn't need to have both methods, I'd just go for getElementsBySelector()

[03:52:01.0000] <othermaciej>
I hate how long it is

[03:52:02.0000] <annevk>
yeah, me too

[03:52:03.0000] <Lachy_>
I know, me too

[03:52:04.0000] <othermaciej>
cssQuery

[03:52:05.0000] <othermaciej>
short, unambiguous

[03:52:06.0000] <annevk>
matchAll and matchSingle is already implemented :)

[03:52:07.0000] <Lachy_>
I'm not a fan of having css in the name

[03:53:00.0000] <othermaciej>
css is inaccurate

[03:53:01.0000] <annevk>
are, even

[03:53:02.0000] <othermaciej>
but is also a very common name for the similar function in JS libraries

[03:53:03.0000] <Lachy_>
yeah, that's a good argument in favour of the match* methods

[03:53:04.0000] <othermaciej>
people call it a "css query api"

[03:53:05.0000] <annevk>
terrible

[03:54:00.0000] <othermaciej>
microsoft's implementation comments were weird

[04:01:00.0000] <Lachy_>
/me mailed public-webapi with the list of alternatives and the summary of the arguments

[04:06:00.0000] <annevk>
getElementByGroupOfSelectors() and getElementsByGroupOfSelectors() all the way

[04:09:00.0000] <virtuelv>
annevk: at this point there are so many suggestions, I suggest going with magic() and blackMagic() :-P

[04:25:00.0000] <Dashiva>
Wow, that's a lot of names

[04:26:00.0000] <zcorpan_>
foo()

[04:29:00.0000] <annevk>
sss() and aaa()

[04:31:00.0000] <BenWard>
document.gifv()

[04:31:01.0000] <Dashiva>
dwiw?

[04:37:00.0000] <virtuelv>
document.gtfo()

[04:52:00.0000] <Lachy>
what's gifv, dwiw and gtfo?

[04:52:01.0000] <Dashiva>
do what I want, get the f* out

[04:53:00.0000] <Dashiva>
But how about making two names? E.g. both getElementsBySelector and gEBS. Then everyone should be happy :)

[04:54:00.0000] <Lachy>
"I guess that's the nice thing about getElementsBySelector. It's like picking 6 names all at once. :)" --  http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0049.html

[04:55:00.0000] <Lachy>
6 > 2!

[04:59:00.0000] <Philip`>
Call them $$$ and $$$s

[05:00:00.0000] <Lachy>
I'll just let each UA implement whatever they like and let the market decide

[05:00:01.0000] <Dashiva>
I know

[05:00:02.0000] <Dashiva>
Make them use kanji

[05:00:03.0000] <Dashiva>
Then they can be short and detailed at the same time!

[05:01:00.0000] <Lachy>
I could go with ⺽⻤()

[05:02:00.0000] <Lachy>
(no idea what that means, I just picked 2 random chinese characters)

[05:03:00.0000] <Dashiva>
Seems they didn't make it past the encoding boundries either

[05:03:01.0000] <Lachy>
they were encoded as UTF-8

[05:03:02.0000] <Dashiva>
But that will just make it easier for authors to check they're using the right encoding!

[05:04:00.0000] <annevk>
yeah, someone should just implement match() and matchAll() and we're done :)

[05:05:00.0000] <Dashiva>
Can't we just have one method, matchBySelector and overload it?

[05:07:00.0000] <annevk>
hmm

[05:08:00.0000] <Lachy>
the reason for having the single method is that it's more efficient when you only want the first element.

[05:10:00.0000] <Dashiva>
Well, the JS match solves that by having a global flag on/off on the regexp. 

[05:10:01.0000] <Philip`>
I guess it's not more efficient when you only want one element and you're selecting it by ID (which I guess might be the most common single-selection situation)

[05:10:02.0000] <Lachy>
the issue is that most use cases for wanting a single element are covered by gEBId or things like document.body

[05:11:00.0000] <Lachy>
match("#a, #b, #c") is an interesting use case when you want whichever comes first or whichever is present in the document

[05:11:01.0000] <annevk>
hopefully this method name is short enough that it can obsolete the need for getElementById

[05:12:00.0000] <annevk>
and getElementsByTagName

[05:12:01.0000] <Philip`>
document.match(/.e + ul li > a/g)

[05:13:00.0000] <Philip`>
and rewrite the ECMAScript language a bit

[05:14:00.0000] <Lachy>
rewrite it like E4X did?

[05:14:01.0000] <Lachy>
should we make E5X?

[05:14:02.0000] <Dashiva>
ES4 is already rewriting it plenty

[05:15:00.0000] <Lachy>
annevk, what was your rationality for choosing matchSingle over matchOne?

[05:17:00.0000] <annevk>
people argued it sounded better and I agreed

[05:17:01.0000] <annevk>
I'm all for .match though

[05:17:02.0000] <annevk>
we should make E5H

[05:18:00.0000] <Philip`>
I'm sure you could set up some kind of type inference to work out that "var x = /a+b/; "aaaaab".match(x)" uses regexp parsing rules when setting x, and "var x = /a+b/; document.match(x)" uses CSS selector rules, and "var x = /a+b/; "aa".match(x); document.match(x)" would be a type error with an entirely incomprehensible error message

[05:19:00.0000] <Lachy>
.match was the name that started this whole debate.  I'm not sure going back to it would solve anything

[05:20:00.0000] <Lachy>
I prefer matchOne over matchSingle, but not enough to justify changing it given that there's already an implementation in base2

[05:22:00.0000] <annevk>
matchOne is also harder to type on a qwerty keyboard than matchSingle

[05:22:01.0000] <annevk>
for me, anyway

[05:22:02.0000] <annevk>
but I suppose I could get used to either

[05:22:03.0000] <annevk>
DeanE said he could change the name btw, or alias it

[05:23:00.0000] <Lachy>
yeah, I know he could change it easily

[05:23:01.0000] <Lachy>
I don't see how One is easieer to type than Single

[05:30:00.0000] <annevk>
we need to add HTMLElement.isContentEditable and several things like queryCommand... on HTMLDocument...

[05:34:00.0000] <annevk>
queryCommandEnabled,  queryCommandValue, queryCommandSupported

[05:39:00.0000] <Dashiva>
matchOnce?

[06:13:00.0000] <zcorpan_>
Hixie: comments in #writing needs to say that comments must not begin with > or ->

[07:33:00.0000] <annevk>
/me implemented new-style <nobr>

[07:34:00.0000] <annevk>
It seems end tag handling of some elements has also changed

[07:35:00.0000] <annevk>
most notably "/body" and "/head"

[07:43:00.0000] <Philip`>
Hmph, now I have enough tests that Safari won't run them all simultaneously without dropping the last couple of dozen and randomly crashing :-(

[07:44:00.0000] <annevk>
that's good :)

[07:45:00.0000] <annevk>
have you filed bugs on them already?

[07:45:01.0000] <annevk>
(I implemented new-style <link>, <meta>, <base> in html5lib)

[07:45:02.0000] <annevk>
jgraham, you need to fix the encoding sniffer for comment handling

[07:48:00.0000] <rubys>
found a bug in the html serializer: <p>a&lt;b&gt;c</p>  =>  <p>a<b>c</p>; but only if a character encoding is specified.

[07:49:00.0000] <annevk>
does the html serializer implement the innerHTML algorithm?

[07:49:01.0000] <Philip`>
Looks like it's actually an intentional limit in WebKit - it won't display more than 200 iframes on a page

[07:49:02.0000] <annevk>
I honestly haven't followed all these treewalker, etc. additions

[07:49:03.0000] <rubys>
don't see 'inner' anywhere in the serializer.

[07:52:00.0000] <annevk>
maybe t.broyer should be invited on IRC...

[07:56:00.0000] <Philip`>
Hmm, can't do more than 200 of <object> either

[07:56:01.0000] <annevk>
maybe 200 object + 200 iframe? :)

[07:57:00.0000] <rubys>
Philip: perhaps you should get another browser?  :-P

[07:57:01.0000] <annevk>
I wonder what the rationale is for this change: http://html5.org/tools/web-apps-tracker?from=917&to=918

[07:57:02.0000] <Philip`>
Seems to be limit of 200 on num_object+num_iframe

[07:58:00.0000] <Philip`>
rubys: Unfortunately I can't use another browser to run test cases in Safari :-(

[07:59:00.0000] <rubys>
/me was joking

[08:00:00.0000] <Philip`>
Ooh, it even works fine in IE6

[08:00:01.0000] <Philip`>
(except for failing pretty much all of the test cases, obviously)

[08:05:00.0000] <annevk>
you know what, I'll just implement the above change and see what happens

[08:09:00.0000] <Philip`>
Also, I can't even do >200 iframes by having 16 iframes each containing 16 iframes

[08:10:00.0000] <annevk>
that's what I was afraid of

[08:10:01.0000] <annevk>
no testcase breaks

[08:10:02.0000] <rubys>
what change?

[08:11:00.0000] <annevk>
see the link above

[08:11:01.0000] <annevk>
http://html5.org/tools/web-apps-tracker?from=917&to=918

[08:12:00.0000] <Philip`>
http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/html/HTMLFrameElementBase.cpp#L72

[08:13:00.0000] <Philip`>
/me supposes he just has to do fewer tests at a time

[08:15:00.0000] <annevk>
wow, sites rely on self-references

[08:15:01.0000] <annevk>
I suppose the aforementioned change affects whitespace handling

[08:24:00.0000] <annevk>
the change also affects handling of </body><meta> for instance

[08:25:00.0000] <annevk>
I'm not sure this was a good change

[08:27:00.0000] <annevk>
mailed the list

[08:32:00.0000] <annevk>
changing how </p> works breaks quite a lot of tests

[08:41:00.0000] <annevk>
I left that change out for now

[08:43:00.0000] <Philip`>
Aha, it works (about half the time, randomly) in Safari if I add a button which deletes all the iframes for completed tests and then recreates the iframes for tests that haven't loaded yet, and if I then change the text size up and down so it redraws the screen properly

[08:43:01.0000] <Philip`>
...which is a totally horrible hack, but then I already need another hack to replace <iframe> with <object> so that it stops being invisible in Safari

[08:44:00.0000] <Philip`>
(though it only does that after it's finished loading the iframes, because it looks like onload doesn't run on objects)

[08:44:01.0000] <annevk>
why do you recreate the iframes?

[08:44:02.0000] <annevk>
just set frame.location ...

[08:48:00.0000] <Philip`>
That doesn't appear to work (is location only set after it's decided it's acceptable to load that iframe?), but it looks like setAttribute('src', getAttribute('src')) does it, so that's a bit nicer

[08:49:00.0000] <Philip`>
/me should probably just split the test-report-generating page into several pages of ~100 tests, and do something cleverer on the server side to merge all the results

[09:15:00.0000] <annevk>
rubys, aren't < and > conforming in XML attribute values?

[09:21:00.0000] <annevk>
/me wonders how the hell XMLHttpRequest.responseBody works

[09:24:00.0000] <annevk>
here's something to play with: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21doctype%20html%3Exxx%0D%0A%3Cscript%3E%0D%0A%20var%20r%20%3D%20new%20XMLHttpRequest%28%29%3B%0D%0A%20r.open%28%22GET%22%2C%20%22image%22%2C%20false%29%3B%0D%0A%20r.send%28%29%0D%0A%20var%20z%20%3D%20r.responseBody%3B%0D%0A%20for%20%28x%20in%20z%29%7B%0D%0A%20%20%20w%28z%5Bx%5D%29%0D%0A%20%7D%0D%0A%3C/script%3E

[09:25:00.0000] <gsnedders>
annevk: no, neither are conforming. [^<&>] is the definition, IIRC

[09:26:00.0000] <annevk>
data:text/html,<test test="<>">x</test>

[09:26:01.0000] <gsnedders>
actually, > is conforming.

[09:26:02.0000] <annevk>
please explain the lack of well-formedness error

[09:26:03.0000] <annevk>
oops

[09:26:04.0000] <annevk>
you're right

[09:26:05.0000] <gsnedders>
[10]    AttValue    ::=    '"' ([^<&"] | Reference)* '"'

[09:26:06.0000] <annevk>
< isn't

[09:26:07.0000] <gsnedders>
(or with single quotes)

[09:26:08.0000] <annevk>
testcase should've been data:text/xml,<test test="<>">x</test>

[09:27:00.0000] <annevk>
they could easily allow < there...

[09:27:01.0000] <gsnedders>
but this is XML!

[09:27:02.0000] <gsnedders>
maybe due to it being a subset of SGML?

[09:28:00.0000] <annevk>
couldn't care less

[09:28:01.0000] <mitsuhiko>
is it <option selected> or <option selected="selected">?

[09:28:02.0000] <annevk>
either

[09:28:03.0000] <mitsuhiko>
awesome

[09:28:04.0000] <annevk>
or <option selected="">

[09:28:05.0000] <mitsuhiko>
annevk: is there a preferred way?

[09:29:00.0000] <annevk>
not really

[09:29:01.0000] <gsnedders>
isn't the value irrelevant, from the UA conformance POV?

[09:29:02.0000] <annevk>
yes

[09:29:03.0000] <annevk>
from an authoring point of view it isn't though

[09:29:04.0000] <annevk>
it's either the empty string or the attribute name

[09:31:00.0000] <gsnedders>
where is that defined in the spec (as the form elements currently reference WF2 which references HTML4) or is it not yet?

[09:31:01.0000] <annevk>
it's defined for things like contenteditable

[09:31:02.0000] <annevk>
Web Forms 2 is yet to be integrated

[09:32:00.0000] <gsnedders>
so it's really undefined as of writing in that case

[09:32:01.0000] <annevk>
the writing section defines those type of attributes

[09:33:00.0000] <annevk>
the concept boolean attribute is defined by the HTML5 spec

[09:34:00.0000] <gsnedders>
it doesn't appear to be defined what happens with a bool attribute when it exists but isn't either an empty string or the attribute's name

[09:34:01.0000] <annevk>
it is

[09:34:02.0000] <rubys>
annevk: in XML, > is legal in attribute values, but < is not

[09:35:00.0000] <gsnedders>
annevk: where?

[09:35:01.0000] <annevk>
"The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value."

[09:35:02.0000] <gsnedders>
annevk: duh. of course the next section doesn't apply.

[09:35:03.0000] <gsnedders>
s/section/paragraph

[09:36:00.0000] <annevk>
that applies just to authors, yes

[09:42:00.0000] <gsnedders>
hmm… you seem to be able to get the SGML handbook second-hand in good condition for less than a third of the cost of the ISO spec

[10:28:00.0000] <rubys>
annevk: you there?

[12:06:00.0000] <duryodhan>
hey, some told me this : 

[12:06:01.0000] <duryodhan>
irefox implements the canvas element which is

[12:06:02.0000] <duryodhan>
actually able to catch part of the screen as bitmap and display it to

[12:06:03.0000] <duryodhan>
the user. It is also able to convert the bitmap to base64. 

[12:06:04.0000] <duryodhan>
*firefox

[12:06:05.0000] <duryodhan>
is this true?

[12:06:06.0000] <duryodhan>
about the canvas element?

[12:08:00.0000] <Dashiva>
Safari, Opera and Firefox all implement canvas

[12:09:00.0000] <duryodhan>
yes ...

[12:09:01.0000] <duryodhan>
I know that ...

[12:09:02.0000] <duryodhan>
I am saying can Canvas do that ...

[12:09:03.0000] <duryodhan>
(save a part of page as bitmap and then save it as base64)

[12:10:00.0000] <Dashiva>
You mean basically print-screen the page and then work with that?

[12:10:01.0000] <duryodhan>
yeah

[12:10:02.0000] <duryodhan>
kinda

[12:10:03.0000] <Philip`>
Firefox has a non-standard extension which lets privileged content (like extensions) draw HTML elements into the canvas

[12:11:00.0000] <duryodhan>
where?

[12:11:01.0000] <Philip`>
(which I believe is used by e.g. the tab preview extension)

[12:11:02.0000] <bewest>
yeah, a lot of people who prorivide screenshot services use that feature

[12:11:03.0000] <duryodhan>
so can I do it through HTML + JS ?

[12:12:00.0000] <duryodhan>
or will it always require an extension?

[12:12:01.0000] <duryodhan>
and can it convert it to base64

[12:13:00.0000] <Philip`>
I can't see any documentation, but it looks like it's ctx.drawWindow(htmlelement, x, y, w, h, backgroundcolour)

[12:13:01.0000] <Philip`>
but you'll always get a security exception if you try doing that from normal web content

[12:14:00.0000] <duryodhan>
but if user adds the domain to trusted ... do you still get that ?

[12:15:00.0000] <Philip`>
That still won't let it run; though I think it's possible to make web content ask the user for universal read privileges, in which case it would be allowed

[12:15:01.0000] <Philip`>
(though you probably have to be a trusted site before even being able to ask for permission)

[12:16:00.0000] <Philip`>
(and you have to ask for permission every time you want to use drawWindow)

[12:16:01.0000] <duryodhan>
ohh 

[12:16:02.0000] <duryodhan>
stupid mozilla server has klined me :(

[12:16:03.0000] <Philip`>
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');

[12:17:00.0000] <Philip`>
...should give the right privileges, I think

[12:19:00.0000] <Philip`>
Once you've drawn stuff to the canvas, http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#todataurl lets you save it as a bitmap (as a base64-encoded PNG image in a data: URI)

[12:20:00.0000] <duryodhan>
hmm let me try it out then ....

[12:20:01.0000] <Philip`>
/me wonders if people have already complained about Gecko adding non-standard functions to the '2d' context, instead of making a 'moz-2d'

[12:22:00.0000] <Philip`>
(...and adding non-standard arguments to the toDataURL function)

[12:23:00.0000] <duryodhan>
Philip`: what is the ctx in the ctx.drawwindow ?

[12:23:01.0000] <Philip`>
ctx = canvas.getContext('2d')

[12:23:02.0000] <Philip`>
where canvas is a <canvas> element

[12:24:00.0000] <Philip`>
(...which should be big enough to fit whatever you want to draw into it)

[12:24:01.0000] <duryodhan>
and the html element is lets say div ? or is it canvas again?

[12:25:00.0000] <Philip`>
(You can do 'canvas = document.createElement('canvas'); canvas.width = 123; canvas.height = 456' if you want a canvas element without actually having one in the HTML document)

[12:26:00.0000] <Philip`>
The htmlelement in the first argument to drawWindow can be any HTML element at all

[12:26:01.0000] <Philip`>
or at least I assume it can be - I've never actually tried this myself :-)

[12:27:00.0000] <Philip`>
http://weblogs.mozillazine.org/roc/archives/2005/05/rendering_web_p.html has an example using drawWindow, and it looks like the interface hasn't changed since then

[12:36:00.0000] <duryodhan>
http://pastebin.ca/579563

[12:36:01.0000] <duryodhan>
us that ok?

[12:36:02.0000] <duryodhan>
how do I get the png file ?

[12:54:00.0000] <Philip`>
duryodhan: Hmm, looks like I was wrong about it accepting any HTML element - it has to be a window object

[12:55:00.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/drawwindow.html (when run from local disk so it's more-trusted) seems to work for me

[12:55:01.0000] <Philip`>
It draws the whole page window into the canvas, and then uses toDataURL to get an address which can be used in <img src> or could be parsed to get the actual PNG data

[13:00:00.0000] <duryodhan>
Philip`: ohh ok 

[13:00:01.0000] <duryodhan>
it works for me too...

[13:00:02.0000] <duryodhan>
but then the problem is still there ...

[13:01:00.0000] <duryodhan>
I don't think an actual page can do this cos it requires that page be on local disk

[13:01:01.0000] <duryodhan>
btw,

[13:01:02.0000] <duryodhan>
it is showing it to me twice ...

[13:02:00.0000] <Philip`>
Is there some way to mark pages as trusted in FF? That ought to make it work the same as files on disk, I think, though I can't work out where you find that option

[13:03:00.0000] <Philip`>
It should be showing the original text once, and then the rendered version in the <canvas>, and then the toDataURLd version in the <img> just to the right

[13:03:01.0000] <duryodhan>
yes 

[13:03:02.0000] <duryodhan>
thats right

[13:09:00.0000] <duryodhan>
maybe you have to make the html+script signed , package them as jar files with signtool and then access them...

[13:09:01.0000] <duryodhan>
http://www.mozilla.org/projects/security/components/signed-scripts.html

[13:09:02.0000] <duryodhan>
search for using signtool in that

[13:09:03.0000] <Philip`>
Hmm, sounds painful

[13:09:04.0000] <duryodhan>
yeah

[13:10:00.0000] <duryodhan>
for the devel 

[13:10:01.0000] <duryodhan>
not for the client 

[13:10:02.0000] <Philip`>
Sounds like it might be easier just to write an extension, particularly since that could avoid asking the user for permission every time

[13:11:00.0000] <duryodhan>
an extension that does what ?

[13:11:01.0000] <duryodhan>
takes a snap when told and saves it

[13:11:02.0000] <duryodhan>
suppose I want to submit the base64 to the server (of the canvas)

[13:11:03.0000] <duryodhan>
in a form ...

[13:15:00.0000] <Philip`>
An extension that does whatever you're trying to do that Firefox normally objects to

[13:16:00.0000] <Philip`>
You should be able to just call toDataURL and put the resulting string in a form field and submit that, though you'll probably have to strip off the "data:image/png;base64," before trying to decode it into a real PNG

[13:16:01.0000] <Philip`>
(It's not guaranteed to be base64, but I don't know of any implementation that doesn't do that, and you can't do drawWindow in a vaguely cross-browser way anyway)

[13:20:00.0000] <zcorpan>
seems like ie stops appending characters to the string when getting innerHTML after it has dealt with the children of a plaintext element

[13:20:01.0000] <zcorpan>
hmm, wc

[13:58:00.0000] <jgraham>
annevk: Can you file a bug on me about the character encoding change? I am really swamped with stuff at the moment so I'm missing out on all the html5lib fun :(

[14:11:00.0000] <Hixie>
i really have no idea how to describe the rules for CDATA and RCDATA

[14:11:01.0000] <Hixie>
for authors

[14:21:00.0000] <hsivonen>
Hixie: delegate to tutorial volunteers perhaps to see what they come up with?

[14:29:00.0000] <Hixie>
while i am sure that what they would come up with would be quite helpful to authors, i don't think it would be airtight

[14:30:00.0000] <hsivonen>
yeah.

[14:30:01.0000] <hsivonen>
it seems that few people appreciate the airtight restatement in prose :-(

[14:31:00.0000] <Philip`>
/me wonders how to test (and report results for) optional features, like gradient rendering, where there are different requirements if the feature is not supported, but there's no way to really tell whether the UA is actually trying to support the feature (but buggily) or intentionally and consistently choosing to not support it

[14:31:01.0000] <Hixie>
hsivonen: the target audience of the syntax section is basically me -- or rather, spec lawyers in years to come. i don't want them to have to prove their case about whether something is conforming or not by walking the parsing algorithm

[14:33:00.0000] <hsivonen>
Hixie: I understand. I'd expect those who markp calls "assholes" to prefer airtight prose over walking the algorithm

[14:35:00.0000] <Hixie>
yeah

[14:35:01.0000] <hsivonen>
Hixie: perhaps define them in terms of a sequence of subparts like "escaped run", "unescaped text", "entity"

[14:35:02.0000] <Hixie>
that's basically the target audience

[14:36:00.0000] <Hixie>
yeah, i think i'll basically have to do that

[14:36:01.0000] <Hixie>
though not with the word "entity"!

[14:36:02.0000] <hsivonen>
well entity reference

[14:36:03.0000] <hsivonen>
for RCDATA

[14:37:00.0000] <Hixie>
oh right

[14:37:01.0000] <Hixie>
indeed

[16:38:00.0000] <zcorpan>
http://www.bernzilla.com/item.php?id=875

[16:40:00.0000] <Hixie>
oops

[16:40:01.0000] <Hixie>
/me replies to a mail without noticing it was sent to a mailing list

[16:40:02.0000] <Hixie>
/me whistles innocently and moves on to the next mail

[16:41:00.0000] <Hixie>
zcorpan: hey, finally someone who agrees with me!

[16:41:01.0000] <zcorpan>
Hixie: yeah :)

[16:43:00.0000] <zcorpan>
actually, i feel "dirty" too, i just think that it's not really harmful and authors changing their documents to insert div tags around images to conform to html5 are wasting their time

[16:43:01.0000] <Hixie>
i was talking to citoyen yesterday about this

[16:43:02.0000] <Hixie>
the only reason we have <div> is to allow custom widgets to be made

[16:44:00.0000] <Hixie>
i can't work out how to make it hard to abuse it

[16:47:00.0000] <zcorpan>
if you make it hard to abuse div, people will abuse something else... :)

[16:47:01.0000] <zcorpan>
(like table)

[16:48:00.0000] <Hixie>
<table>, <br>, and <div> are the main ones i'm worried about being abused

[16:48:01.0000] <Hixie>
<table> is being dealt with by education

[16:49:00.0000] <Hixie>
moderately successfully, even

[16:51:00.0000] <zcorpan>
<br> is a tough one. i don't know how to not use <br> in a forum that accepts bbcode. people want to be able to make one, two, three, many line-breaks. fwiw, they also aren't going to mark up headings in any other manner than pressing the BOLD button and hitting enter

[16:52:00.0000] <zcorpan>
(well, i guess a heading bbcode tag could be introduced -- that was an aside)

[16:53:00.0000] <Hixie>
the contents of forum postings are equivalent to wysiwyg editor output

[16:53:01.0000] <zcorpan>
yeah

[16:53:02.0000] <Hixie>
i don't know how to handle those either

[16:53:03.0000] <zcorpan>
it's not trivial

[16:53:04.0000] <Hixie>
the <meta generator> idea didn't go down well

[16:53:05.0000] <zcorpan>
indeed

[16:56:00.0000] <zcorpan>
about div and what it means... perhaps when it contains block-level content, it means nothing, and when it contains inline-level content, it means a thematic group

[16:57:00.0000] <zcorpan>
or it always means a thematic group

[16:57:01.0000] <Hixie>
isn't that what <section> is?

[16:57:02.0000] <zcorpan>
section affects the document outline, div doesn't

[16:58:00.0000] <Hixie>
i suppose i could buy your block vs inline semantics definition

[16:59:00.0000] <Hixie>
but when it contains blocks, it really means nothing, imho

[16:59:01.0000] <Hixie>
that, btw, is why i didn't want it containing inlines in the first place

[16:59:02.0000] <zcorpan>
yeah


2007-06-21
[17:01:00.0000] <Hixie>
if <div>-containing-inline is "thematic group", what's the difference between <div> and <p>?

[17:01:01.0000] <Hixie>
maybe i should just bite the bullet and make them equivalent in the spec

[17:01:02.0000] <Hixie>
<div>-containing-inline and <p>, i mean

[17:01:03.0000] <Hixie>
not <div>-containing-block

[17:02:00.0000] <zcorpan>
i would be ok with that

[17:19:00.0000] <zcorpan>
Hixie: somehow your scripts converted "<code title="attr-style-scoped">scoped</code> attribute" to "<code title=attr-style-scoped><a href="#scoped"></a></code>"

[17:20:00.0000] <Hixie>
i probably edited the file while the thing was being generated

[17:20:01.0000] <Hixie>
i'm using bert's script to do the cross-references

[17:20:02.0000] <Hixie>
it runs on cgi.w3.org

[17:20:03.0000] <Hixie>
and takes three years per generetion

[17:20:04.0000] <zcorpan>
ok :)

[17:21:00.0000] <Hixie>
and i have to do two each time i do a checkin (one for the w3.org version and one for the whatwg.org version)

[17:22:00.0000] <zcorpan>
oh yep

[17:23:00.0000] <Hixie>
so that's six years :-P

[17:24:00.0000] <Hixie>
yeah, looks like i changed the file while i was generating it

[17:24:01.0000] <Hixie>
d'oh

[17:24:02.0000] <Hixie>
oh well

[17:24:03.0000] <Hixie>
fixed

[17:33:00.0000] <Hixie>
i wonder why i used a different technique for <xmp> as for the other CDATA elements

[17:53:00.0000] <webben>
Hixie: If div may be used for custom widgets (as it is in the wild), then treating div with inline children like p would presumably break paragraph to paragraph navigation.

[17:54:00.0000] <webben>
Is your current view that div-as-custom-widget be conforming, non-conforming but specified, or non-conforming and unspecified?

[17:55:00.0000] <webben>
Hixie: Having said that, it might be worth defining special parsing for p containing certain children, such as blockquote.

[17:55:01.0000] <webben>
(where stuff which can go into print paragraphs cannot go into text/html paragraphs)

[17:56:00.0000] <webben>
*special parsing for div containing certain children, sorry

[17:56:01.0000] <Hixie>
webben: conforming but discouraged in favour of things like xbl2

[17:58:00.0000] <webben>
Hixie: How about processing WAI-ARIA attributes for such widgets then?

[17:58:01.0000] <webben>
which category would that fall into?

[18:03:00.0000] <webben>
btw examples of paragraph-by-paragraph navigation include: https://addons.mozilla.org/en-US/firefox/addon/2266 and http://images.apple.com/accessibility/voiceover/pdf/VoiceOverKeyboard_Color_v2.pdf and http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_rnib003398.hcsp and http://www.gwmicro.com/window-eyes/manual/html/index.html?appendix_a_1.htm (though note this doesn't necessarily equal navigation by <p>)

[18:03:01.0000] <webben>
e.g. "Window-Eyes defines paragraphs as any collection of elements that contain blank space both above and below the collection, regardless of whether that collection contains text, or any other element."

[18:04:00.0000] <Hixie>
i don't really understand any of your questions :-)

[18:04:01.0000] <Hixie>
we already have, e.g., <li> defined to be a paragraph

[18:04:02.0000] <Hixie>
i don't understand what the processing of WAI-ARIA would get us (they're woefully underdefined and redundant with most of what's already in HTML anyway)

[18:06:00.0000] <webben>
Hixie: It seems to be a fundamental premise of WAI-ARIA to prefer native widgets where available (which seems to be exactly the same as the position you're suggesting WHATWG adopt). WAI-ARIA is clearly not redundant for custom widgets since they aren't in HTML.

[18:06:01.0000] <webben>
Hixie: They don't seem to be so underdefined that Mozilla and AT can't implement them.

[18:07:00.0000] <webben>
Does WHATWG have an alternative proposal for accessifying such widgets in current browsers and AT?

[18:08:00.0000] <Hixie>
WAI-ARIA is redundant for most (all?) the widgets it supports, as they are all defined in HTML5 as far as I can tell.

[18:09:00.0000] <webben>
Hixie: WAI-ARIA doesn't support just a set of widgets but also a set of properties and states. Can Dojo use HTML5 widgets in current UAs and have them look as "nice" as their existing widget set?

[18:10:00.0000] <webben>
Mozilla doesn't seem to support some of the more basic HTML5 widgets yet ... e.g. slider.

[18:11:00.0000] <othermaciej_>
HTML5 doesn't define how to do widgets with custom look or behavior (in itself)

[18:11:01.0000] <Hixie>
they are underdefined, for example it is not at all clear what it would mean if you had a document with a wairole:treeitem as a child of a waitrole:checkbox or some such

[18:11:02.0000] <Hixie>
WAI-ARIA and HTML5 both define new technologies, and therefore don't work in legacy UA ATs

[18:11:03.0000] <webben>
Hixie: Legacy UA AT != current UA ATs

[18:11:04.0000] <Hixie>
by "Legacy UA AT" i mean the currento nes

[18:12:00.0000] <Hixie>
ones

[18:12:01.0000] <Hixie>
as opposed to the ones that support the technologies in question

[18:14:00.0000] <webben>
Hixie: The breakage is not the same. You cannot write Dojo widgets in HTML5 and get them to look "nice" in IE. But you can write Dojo widgets and get them to look "nice" in all modern browsers, but also be accessible in Mozilla (and thus to major AT).

[18:15:00.0000] <Hixie>
i disagree, but that's not really important

[18:15:01.0000] <webben>
With which bit? The cannot or the can?

[18:15:02.0000] <Hixie>
that you can't use the HTML5 elements and have them look good in IE

[18:16:00.0000] <Hixie>
it's just a matter of using the right elements and then replacing them in script with whatever you want to replace them with

[18:16:01.0000] <Hixie>
but anyway, i'm more interested in the long term solution to this

[18:16:02.0000] <Hixie>
which is, imho, to use xbl2 and html5

[18:16:03.0000] <othermaciej>
(or just CSS styling of form controls for simple cases if there's ever sufficiently interoperable support for that)

[18:16:04.0000] <Hixie>
yeah

[18:17:00.0000] <Hixie>
imho the wai-aria/role stuff is a distraction that is merely slowing the adoption rate for the long-term solutions

[18:17:01.0000] <Hixie>
wai-aria/role aren't scalable, and are far too complicated to implement by most authors

[18:17:02.0000] <othermaciej>
well, the long-term solutions are much more complex in terms of required browser engineering to deploy

[18:18:00.0000] <Hixie>
right

[18:18:01.0000] <webben>
Hixie: I doubt accessibility is the major driver for XBL2 adoption, so I doubt that's the case.

[18:18:02.0000] <Hixie>
the complexity is placed in the UAs, rather than the authors

[18:18:03.0000] <webben>
Hixie: Custom widgets are too complicated to implement by most authors full stop.

[18:18:04.0000] <webben>
(XBL2 is way too complex)

[18:18:05.0000] <Hixie>
(that's the right way to do it, it reduces the total implementation cost to the human race)

[18:18:06.0000] <Hixie>
anyway, gotta go, meeting

[18:18:07.0000] <Hixie>
bbl

[19:01:00.0000] <Philip`>
/me finally gets his multiplayer FPS working cross-browser (or at least across two browsers)

[19:58:00.0000] <Philip`>
/me gets up support for three browsers, which is plenty to say that any problems in other browsers are their fault and not mine

[01:06:00.0000] <hsivonen>
annevk: svn co http://svn.versiondude.net/whattf/htmlparser/trunk/  htmlparser

[01:07:00.0000] <hsivonen>
finally got a sane ACL there

[01:40:00.0000] <zcorpan>
Hixie: "Comment parsing is different." -- not anymore, right? only three parsing quirks left :)

[02:17:00.0000] <Hixie>
don't kill me

[02:18:00.0000] <Hixie>
but i'm about to check in major changes to the way <head> is parsed

[02:18:01.0000] <Hixie>
zcorpan: that i know of :-)

[02:18:02.0000] <Hixie>
jesus, this is a 1000 line patch

[02:21:00.0000] <annevk>
dude

[02:21:01.0000] <annevk>
well, I suppose it gives me some more hacking fun :)

[02:22:00.0000] <annevk>
or is this the patch that makes EOF work and gives the tree construction stage just a set of phases

[02:24:00.0000] <annevk>
seems it does indeed take three years before such things make it in :)

[02:30:00.0000] <Hixie>
no, it's the change that allows <noscript> in <head>

[02:30:01.0000] <annevk>
oh

[02:30:02.0000] <Hixie>
btw you might want to give more context for the patches on the tracker page, some of these changes are hard to follow if you don't have 20+ lines of context

[02:31:00.0000] <annevk>
svn diff ...?

[02:31:01.0000] <Hixie>
ironically i think the change to fold phases and insertion modes into one might be simpler -- except it'd probably introduce more bugs :-)

[02:31:02.0000] <Hixie>
dunno what the svn diff command is

[02:31:03.0000] <annevk>
that should be trivial to fix, if someone gives me the relevant command line options

[02:31:04.0000] <Hixie>
i use regular gnu diff

[02:31:05.0000] <Hixie>
in ~/.subversion/config

[02:32:00.0000] <Hixie>
i have, under [helpers]:

[02:32:01.0000] <Hixie>
diff-cmd = /home/ianh/.subversion/diff

[02:32:02.0000] <Hixie>
and that file contains:

[02:32:03.0000] <annevk>
hmm, I'll figure something out

[02:32:04.0000] <Hixie>
#!/bin/bash

[02:32:05.0000] <Hixie>
diff=/usr/bin/diff

[02:32:06.0000] <Hixie>
args="-u20 --new-file --minimal --show-c-function"

[02:32:07.0000] <Hixie>
exec ${diff} ${args} "$@"

[02:32:08.0000] <Hixie>
(--show-c-function isn't useful for the spec)

[02:36:00.0000] <Hixie>
this checkin makes <head> element parsing much simpler

[02:36:01.0000] <Hixie>
though it does add a state

[02:38:00.0000] <Hixie>
right, checked in

[02:42:00.0000] <hsivonen>
Hixie: FYI, http://golem.ph.utexas.edu/%7Edistler/blog/archives/001324.html in case it didn't appear on your radar already

[02:46:00.0000] <annevk>
hmm, in theory scripting does not have to be enabled for fragment parsing

[02:46:01.0000] <Hixie>
hsivonen: i love how some of hte most important issues are relagated to a footnote

[02:47:00.0000] <Hixie>
annevk: indeed, not any more, not now that it's been abstracted out

[02:47:01.0000] <Hixie>
the only case i think we don't currently handle is error-handling of <noscript> contents in <head> when parsing is disabled and you're doing fragment parsing for a <head>

[02:47:02.0000] <Hixie>
not sure i want to both fixing it though

[02:49:00.0000] <annevk>
yeah, I was reading the diff and spotted that edge case you mentioned there :)

[02:52:00.0000] <Hixie>
right well, with that checkin, let's try sleeping again

[02:52:01.0000] <Hixie>
nn

[02:52:02.0000] <annevk>
g'night

[02:54:00.0000] <hsivonen>
nn

[03:30:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0023.html ...

[03:34:00.0000] <zcorpan>
oh, so it is modularization that makes xhtml. well then, xhtml 1.0 needs a new name, too

[03:34:01.0000] <annevk>
these discussions don't make sense to me at all

[03:35:00.0000] <annevk>
but I'm not going to get involved

[03:43:00.0000] <zcorpan>
so xhtml2 is not terribly different from xhtml1.1, and thus doesn't need a new namespace. html5 however slightly changes the semantics of <i>, and thus needs a new namespace. yep. makes sense.

[03:44:00.0000] <annevk>
it's not like they don't change the semantics of <input>

[03:44:01.0000] <zcorpan>
/me goes back to writing test cases

[03:49:00.0000] <othermaciej>
zcorpan: xhtml2 is more backwards-compatible than html5!

[03:49:01.0000] <othermaciej>
zcorpan: haven't you heard?

[03:49:02.0000] <zcorpan>
othermaciej: yeah

[03:49:03.0000] <othermaciej>
also, all XHTMLs have always been modular

[03:50:00.0000] <othermaciej>
(except the one people actually use on the web)

[03:52:00.0000] <zcorpan>
i would love to see his comparison though

[03:58:00.0000] <othermaciej>
well, HTML5 slightly changes the semantics of the <i> element and XHTML2 removes it

[03:58:01.0000] <othermaciej>
so there's one example where XHTML2 is more compatible

[03:59:00.0000] <othermaciej>
HTML5 adds some new event listener attributes but XHTML2 removes them all and replaces them with XML Events, so there's another example

[04:01:00.0000] <zcorpan>
then obviously there are different interpretations on what backwards-compatibility means. is it compatibility with existing UAs or compatibility with prior specs?

[04:01:01.0000] <othermaciej>
well, XHTML2 doesn't have either

[04:01:02.0000] <zcorpan>
true

[04:03:00.0000] <othermaciej>
but it does have modules

[04:03:01.0000] <othermaciej>
maybe it is compatible in the sense that you could mix and match modules from XHTML 1.1 and XHTML 2 when making your web-fragmenting frankenlanguage profile

[04:04:00.0000] <zcorpan>
perhaps you would use server-side check if the UA supports xhtml2, and if not, you serve xhtml1.1

[04:05:00.0000] <zcorpan>
or use xslt

[04:11:00.0000] <annevk>
hmm, if citations of minutes are out of context than the minutes have not been done properly...

[04:11:01.0000] <zcorpan>
Hixie: <noscript><meta http-equiv=refresh> ?

[04:12:00.0000] <met_>
Steven: I believe that XHTML2 is more backwards compatible than HTML5, and I plan to make a document comparing them to demonstrate it.  (cannot iin the irc log see the note about document preparing)

[04:13:00.0000] <met_>
/me just comparing http://www.w3.org/2007/06/20-xhtml-minutes#item05 and http://krijnhoetmer.nl/irc-logs/xhtml/20070620

[04:15:00.0000] <annevk>
interesting

[04:16:00.0000] <annevk>
they must have edited things

[04:16:01.0000] <annevk>
not in http://www.w3.org/2007/06/20-xhtml-irc either

[04:35:00.0000] <annevk>
Ok, http://html5.org/tools/web-apps-tracker now has -up20 enabled and an updated title

[04:35:01.0000] <annevk>
I'll commit the changes

[04:40:00.0000] <annevk>
let me know if it is too much context

[04:40:01.0000] <annevk>
it takes some time for me to get used to it

[04:40:02.0000] <annevk>
at least

[05:23:00.0000] <zcorpan>
htmlcollections are fun

[05:24:00.0000] <annevk>
and browsers are broken?

[05:24:01.0000] <zcorpan>
no, they work fine, although they don't interoperate on some points

[05:25:00.0000] <zcorpan>
for document.links, firefox only filters for <area href> when there is a <map> ancestor

[05:26:00.0000] <zcorpan>
for document.anchors, ie filters for <a> elements with a non-empty id or name attribute

[05:26:01.0000] <annevk>
that makes sense

[05:28:00.0000] <zcorpan>
what ie does for .anchors?

[05:28:01.0000] <Philip`>
When the spec says HTMLCollection has "a [[Get]] method that, ... when invoked with a property name that is a string, acts like the namedItem() method would when invoked with that argument", isn't that wrong because collection['item'] gives the item function and is not the same as collection.namedItem('item')?

[05:29:00.0000] <zcorpan>
haven't tested namedItem yet

[05:29:01.0000] <zcorpan>
only which elements that are filtered for so far

[05:29:02.0000] <zcorpan>
not done with all collections either

[05:30:00.0000] <zcorpan>
should get some lunch first

[05:31:00.0000] <annevk>
Philip`, same goes for collection["length"]; I guess that will be solved once [[Get]] is defined at the IDL-level instead of paragraph-level

[05:31:01.0000] <Philip`>
Oh, actually,  <b id=item></b> ... c = getElementsByTagName('b'); c['item']  gives the HTML element in IE6 and Opera, but gives the item function in Firefox

[05:31:02.0000] <annevk>
ooh

[05:32:00.0000] <annevk>
cool

[05:32:01.0000] <Philip`>
(If nothing has id=item, then IE6 and Opera give the item function)

[05:32:02.0000] <annevk>
not cool

[05:47:00.0000] <Philip`>
Hmm, there's loads of ways it doesn't match IE6 - there's interesting behaviour in <a id=x></a><a id=null></a><a id=10></a> ... c[null]; c.item(null); c.namedItem(null); c[10]; c["10"]; c.item(10); c.item("10");

[07:12:00.0000] <annevk>
interesting

[07:12:01.0000] <annevk>
for namedItem() it stringifies and for item() it makes itself 0

[07:12:02.0000] <annevk>
for c[] it throws

[07:14:00.0000] <annevk>
hmm... item("10") is weird

[07:14:01.0000] <annevk>
so is item("null")

[07:23:00.0000] <Philip`>
Ooh, I never knew you could do something like Object.prototype.toString.call(ctx) to work out the [[Class]] of an object

[07:29:00.0000] <Lachy>
annevk, don't you agree with my answer to the .match(":root") matching in document fragments?

[07:33:00.0000] <annevk>
dunno

[07:33:01.0000] <annevk>
didn't follow all of the discussion

[07:34:00.0000] <Lachy>
oh, well, read my last post on member-webapi

[07:34:01.0000] <annevk>
wtf

[07:34:02.0000] <annevk>
_member_?!

[07:34:03.0000] <annevk>
bah

[07:34:04.0000] <Lachy>
yeah, sorry

[07:34:05.0000] <Lachy>
I didn't start the discussion there, just responded to it

[07:35:00.0000] <annevk>
hmm, ok

[07:35:01.0000] <annevk>
it still clashes with the definition of root in HTML5 for lonely elements

[07:36:00.0000] <annevk>
but maybe that doesn't matter

[07:36:01.0000] <zcorpan>
/me wonders what Lachy's answer was

[07:37:00.0000] <annevk>
zcorpan, you should be able to look it up now that you're working for Opera

[07:37:01.0000] <annevk>
zcorpan, if you're in an Opera office that is

[07:37:02.0000] <Lachy>
zcorpan: basically that in fragments that aren't part of a document, there is no root element

[07:38:00.0000] <Lachy>
so :root matches nothing

[07:38:01.0000] <zcorpan>
annevk: how?

[07:38:02.0000] <zcorpan>
Lachy: ok. makes sense

[07:38:03.0000] <annevk>
zcorpan, IP white-listing

[07:38:04.0000] <Philip`>
(Oh, that Object.prototype.toString thing doesn't work in IE (since that just says "[object Object]" all the time), so I guess it's not so helpful for people who care about testing IE :-( )

[07:39:00.0000] <zcorpan>
annevk: i don't follow

[07:40:00.0000] <Lachy>
this one explains it best, if you're able to access it http://lists.w3.org/Archives/Member/member-webapi/2007Jun/0019.html

[07:40:01.0000] <zcorpan>
i'm not

[07:40:02.0000] <annevk>
oh, maybe the swedes are not whitelisted

[07:40:03.0000] <annevk>
/me ponders

[07:43:00.0000] <Lachy>
perhaps I should ask the CSSWG for clarification

[08:23:00.0000] <Lachy>
/me mails www-style about the issue

[08:24:00.0000] <Lachy>
http://lists.w3.org/Archives/Public/www-style/2007Jun/0116.html

[08:27:00.0000] <annevk>
I'm not sure I argued. I just pointed out that that's what HTML5 says

[08:27:01.0000] <annevk>
or HTML5 defines as the "root element"

[08:29:00.0000] <Lachy>
yeah, but Jonas still didn't agree, so I decided it would be worth asking anyway

[08:30:00.0000] <Lachy>
where does HTML5 actually define the root element?

[08:32:00.0000] <Lachy>
it does here http://www.whatwg.org/specs/web-apps/current-work/#the-root but that doesn't really apply to fragments in general

[08:33:00.0000] <Lachy>
there it is http://www.whatwg.org/specs/web-apps/current-work/#root-element

[08:34:00.0000] <annevk>
that definition doesn't really cover subtrees outside the document though or document fragments

[08:35:00.0000] <Lachy>
it sort of does.  it calls them orphaned nodes

[08:53:00.0000] <zcorpan>
fun! <table><form><tr><td><textarea>, then check form.elements

[08:55:00.0000] <Lachy>
it contains the textarea.  Isn't that the expected behaviour?

[08:55:01.0000] <zcorpan>
not in the dom it doesn't

[08:55:02.0000] <annevk>
it does per HTML5

[08:56:00.0000] <annevk>
note how the form element pointer is set

[08:56:01.0000] <Lachy>
yeah, but I had a feeling HTML5 adds it to the forms collections anyway

[08:56:02.0000] <annevk>
and if that's not the case, it's a bug :)

[08:56:03.0000] <annevk>
/me checks

[08:56:04.0000] <zcorpan>
annevk: it will probably be the case when wf2 is merged

[08:57:00.0000] <annevk>
I meant in the parser

[08:57:01.0000] <zcorpan>
oh sure

[08:57:02.0000] <annevk>
I suppose form.elements will be defined in terms of the form element pointer

[08:57:03.0000] <zcorpan>
yeah. it's not right now though

[08:58:00.0000] <zcorpan>
wf2 says to look at the ancestors and the form="" attribute

[08:59:00.0000] <annevk>
fair enough

[08:59:01.0000] <annevk>
<form> parsing prolly needs more testing than this

[09:00:00.0000] <annevk>
than it had so far

[09:01:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0026.html

[09:02:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0025.html is nice too

[09:02:01.0000] <annevk>
"nice"

[09:04:00.0000] <Philip`>
Call it X-HTML5, because it's the XML version of HTML5, so people shouldn't object to that, and then just accidentally drop the hyphen every time you use the name

[09:05:00.0000] <annevk>
1) I haven't seen it cause much confusion. 2) Not all XHTML languages are modular. 3) You want a short name for "XML serialization of HTML5"

[09:06:00.0000] <annevk>
1) see http://blogsearch.google.com/blogsearch?q=xhtml5 2) see XHTML 1.0 and 3) well...

[09:06:01.0000] <annevk>
/me -> food

[09:08:00.0000] <duryodhan>
Philip`: your page canvex.illuminati... the one you had said yesterday ...

[09:08:01.0000] <duryodhan>
I was able to use it from my work comp 

[09:09:00.0000] <duryodhan>
(i.e school comp )

[09:09:01.0000] <Philip`>
The http://canvex.lazyilluminati.com/misc/drawwindow.html one?

[09:09:02.0000] <duryodhan>
I dont know how there it didn't give exception ...

[09:09:03.0000] <duryodhan>
yeah that one

[09:09:04.0000] <duryodhan>
from my home it is giving exception 

[09:09:05.0000] <Philip`>
Hmm, sounds odd

[09:09:06.0000] <duryodhan>
I couldn't contact from school cos it behind a proxy ... IRC blocked :(

[09:10:00.0000] <Philip`>
Given the danger of letting random web sites show the user a dialog box which they won't read and where they'll click on either button at random to make the dialog box go away, when clicking the wrong button will give the web site complete control over the user's computer, I would expect it to be blocked by default...

[09:10:01.0000] <duryodhan>
yes ... that is true ...

[09:10:02.0000] <duryodhan>
but the thing is ...

[09:11:00.0000] <duryodhan>
it worked

[09:11:01.0000] <duryodhan>
:D

[09:11:02.0000] <duryodhan>
/me is also suprised how good chatzilla is

[09:11:03.0000] <Philip`>
But if it works when it shouldn't, that's probably a bug :-)

[09:11:04.0000] <Philip`>
(or a weird configuration option)

[09:11:05.0000] <duryodhan>
exactly ...

[09:12:00.0000] <duryodhan>
what is that weird config ?

[09:12:01.0000] <duryodhan>
I can probably get away with asking ppl to do it 

[09:12:02.0000] <duryodhan>
rofl

[09:13:00.0000] <duryodhan>
brb

[09:13:01.0000] <Philip`>
about:config -> signed.applets.codebase_principal_support = true enables it

[09:14:00.0000] <duryodhan>
Philip`: aaah

[09:15:00.0000] <duryodhan>
signed.applets.codebase_principal_support

[09:15:01.0000] <Lachy>
LOL :-D "Steven: I believe that XHTML2 is more backwards compatible than HTML5, and I plan to make a document comparing them to demonstrate it." -- http://www.w3.org/2007/06/20-xhtml-minutes#item05

[09:15:02.0000] <duryodhan>
toggle that and you are golden 

[09:15:03.0000] <duryodhan>
Lachy: well 

[09:15:04.0000] <Philip`>
duryodhan: Toggle that and you're also much less secure :-)

[09:15:05.0000] <duryodhan>
I believe i can fly ....

[09:16:00.0000] <duryodhan>
Philip`: not me ... client :D

[09:16:01.0000] <duryodhan>
Philip`: not less secure ... you should just stop clicking OK blindly

[09:16:02.0000] <Lachy>
duryodhan: will you produce a document comparing your ability to fly with mine to demonstrate that?

[09:16:03.0000] <duryodhan>
Lachy: I will even make a canvas base64 image of it for you

[09:16:04.0000] <duryodhan>
rofl

[09:17:00.0000] <Lachy>
oh, I'm intrigued now.

[09:19:00.0000] <Philip`>
duryodhan: As far as I can see, codebase_principal_support doesn't directly make anything less secure - it just allows sites to ask for privileges without being identifiable (i.e. not using certificates and stuff)

[09:19:01.0000] <Lachy>
I'm confused by the XHTML2 WG's strange belief that altering the semantics slightly makes a language not backwards compatible, whereas completely changing processing requirements like XHTML2 does remains compatible

[09:19:02.0000] <duryodhan>
Philip`: that is what I was reading up on ...

[09:19:03.0000] <duryodhan>
Philip`: so If I maybe sign my scripts ....

[09:20:00.0000] <duryodhan>
Philip`: then maybe it will ask even if that config isn't toggled...

[09:20:01.0000] <duryodhan>
btw, if you are wondering where in the world I found this obscure option ... see the XML Digital Signature tool Firefox add on

[09:20:02.0000] <Philip`>
Lachy: It might help if they were clearer on what "backward compatibility" they had in mind (like old/new conforming/nonconforming documents in new/old UAs, with UAs implementing latest/all specification, etc)

[09:21:00.0000] <Philip`>
(because it seems you get different constraints and conclusions depending on which forms of compatibility you're interested in)

[09:21:01.0000] <Lachy>
I'll ask steven.  I'm waiting for him to get back so I can speak to him in #xhtml

[09:22:00.0000] <Philip`>
duryodhan: http://www.mozilla.org/projects/security/components/signed-scripts.html talks about Codebase Principals, which seems relevant here

[09:23:00.0000] <duryodhan>
/me wonders why chatzilla links didn't open in a new tab

[09:25:00.0000] <duryodhan>
Philip`: I am still reading but at a glance it seems my hunch was right , that signing scripts would then not require me to enable codebase_principal support

[09:36:00.0000] <Lachy>
duryodhan: if you want links in chatzilla to open a new tab, you need to middle click them

[09:36:01.0000] <duryodhan>
yeah

[09:36:02.0000] <duryodhan>
I realised that now 

[09:37:00.0000] <duryodhan>
I thought It would act as if an outisde app is opening page

[09:37:01.0000] <duryodhan>
(and thus firefox owuld open it in a new tab/window according to my prefs )

[09:38:00.0000] <Lachy>
yeah, it's a little unintuitive.  It should follow that pref

[09:38:01.0000] <Lachy>
but it's not technically an external application

[09:38:02.0000] <Philip`>
/me uses the high-tech strategy of selecting text from IRC in the terminal window, copying, switching to a browser window, opening a new tab, pasting, adding the h at the beginning that usually got missed when selecting the address, then pressing enter

[09:41:00.0000] <Lachy>
Philip`: which IRC client are you using?

[09:42:00.0000] <Philip`>
Lachy: Irssi

[09:43:00.0000] <Lachy>
oh.  I tried that, but gave up on it cause I couldn't click on links

[09:43:01.0000] <Philip`>
Oh :-)

[09:43:02.0000] <gavin_>
terminal.app lets me click on links when I use irssi :)

[09:44:00.0000] <Lachy>
I'm using chatzilla at the moment.  I used to use xchat on my mac, but my mac is faulty and keeps freezing

[09:46:00.0000] <Philip`>
/me is just running in Konsole

[09:46:01.0000] <Philip`>
Ooh, Klipper helps - if I turn its 'actions' on, I can double-click a link and it pops up a little menu with options like "Open in Konqueror", "Open in Mozilla", "Open in Firefox"

[09:47:00.0000] <Philip`>
though somehow I've messed up Konqueror so when I try visiting a web site in it, it saves it to a temporary file and opens Opera instead

[10:03:00.0000] <h3h>
ugh, versioning revisited

[10:06:00.0000] <Philip`>
I don't really see why document validity should be a goal in itself

[10:06:01.0000] <h3h>
it shouldn't

[10:06:02.0000] <h3h>
it's help as a means to an end

[10:08:00.0000] <Philip`>
Then, I don't really see why someone would think document validity is a goal in itself (but it seems some do think that)

[13:40:00.0000] <othermaciej>
does anyone know where to find the latest editor's draft of xhtml2?

[13:40:01.0000] <othermaciej>
the most recent I could find is this: http://www.w3.org/MarkUp/2007/ED-xhtml2-20070402/

[13:41:00.0000] <othermaciej>
I assume it is in w3c cvs somewhere though

[13:46:00.0000] <Hixie>
do people really think that "XHTML2 and XHTML5" is bad but "XHTML2 and XHTML1.5" is good? especially given the reality of the 5>2 thing?

[13:47:00.0000] <Hixie>
i'd have thought 1.5 would be more confusing for authors ("clearly XHTML2 is what i should be using, XHTML1.5 is not as new as XHTML2")

[13:50:00.0000] <othermaciej>
I personally don't care either way

[13:51:00.0000] <othermaciej>
the XHTML 2 WG seems to hate the idea of any use of the XHTML name

[13:51:01.0000] <Hixie>
yeah that's more of a problem

[13:54:00.0000] <Hixie>
as you say in e-mail, the namespace part is worse

[13:54:01.0000] <Hixie>
though i personally think it's a non-issue

[13:54:02.0000] <Hixie>
let them include a fatal flaw in their language

[13:54:03.0000] <Hixie>
it won't affect us in the slightest

[13:54:04.0000] <Hixie>
all it will do is guarentee nobody implements xhtml2

[13:55:00.0000] <othermaciej>
I don't mind them using it

[13:55:01.0000] <othermaciej>
but they want us to change our namespace

[13:55:02.0000] <Hixie>
oh

[13:55:03.0000] <Hixie>
well

[13:55:04.0000] <othermaciej>
because XHTML2 is more compatible

[13:55:05.0000] <Hixie>
that's not even really up for debate

[13:55:06.0000] <Hixie>
i wouldn't pay that much mind

[13:55:07.0000] <Hixie>
there's no way tim would side with them on that

[13:56:00.0000] <Hixie>
i mean, even if by some fluke of reality distortion fields the htmlwg was forced not to use that namespace, i would just make the htmlwg spec not mention the namespace and let the whatwg one handle it

[13:56:01.0000] <Hixie>
it's not an issue

[13:57:00.0000] <othermaciej>
I don't think so either, that's why I think it is ok to ignore them and let the Director settle it if needed

[14:47:00.0000] <Hixie>
http://krijnhoetmer.nl/irc-logs/xhtml/20070530#l-172

[14:48:00.0000] <jruderman>
why is safari's "view source" command disabled on that page?

[14:49:00.0000] <Hixie>
safari doesn't enable it until the page has finished loading

[14:52:00.0000] <jruderman>
it seems finished

[14:54:00.0000] <Hixie>
hm, i learn more about what the htmlwg is doing from the secretive chairs list than i do from the public list

[14:54:01.0000] <Hixie>
http://lists.w3.org/Archives/Member/w3c-html-cg/2007AprJun/0203.html

[14:55:00.0000] <Hixie>
that's sad

[14:57:00.0000] <Hixie>
hm, othermaciej was looking for a list of xhtml2 documents and their status, including latest editor's drafts, it seems that's here: http://www.w3.org/MarkUp/Drafts/Overview.html

[15:01:00.0000] <Philip`>
That makes it sound like the editor's drafts listed there are constantly updated to always be the latest version, but then it looks a bit odd that the latest XHTML2 one is two months old

[15:01:01.0000] <Philip`>
http://www.w3.org/MarkUp/Drafts/autoPublication.html is slightly sparse on the details, sadly :-(

[15:17:00.0000] <Hixie>
i think it's probably accurate that the draft hasn't been updated since april

[15:40:00.0000] <Hixie>
othermaciej: < Hixie>|hm, othermaciej was looking for a list of xhtml2 documents and their status, including latest

[15:40:01.0000] <Hixie>
                       editor's drafts, it seems that's here: http://www.w3.org/MarkUp/Drafts/Overview.html

[15:43:00.0000] <othermaciej>
Hixie: thanks

[15:43:01.0000] <othermaciej>
Hixie: I was wondering if they'd changed the namespace URI yet, it looks like not

[15:43:02.0000] <othermaciej>
Hixie: even though they have been saying for a long time that they don't have a different namespace

[16:17:00.0000] <Hixie>
christ, how hard can this versioning thing be

[16:18:00.0000] <Hixie>
right, afk, bbiab


2007-06-22
[17:34:00.0000] <Hixie>
woot, i'm up to the parsing comments that were sent earlier this month!

[18:40:00.0000] <Philip`>
Woah, the HTML4 DTD has attributes 'datasrc', 'datafld', 'dataformatas' and 'datapagesize' as "reserved for possible future use" - I wonder what they were meant for...

[18:40:01.0000] <othermaciej>
weird

[18:40:02.0000] <othermaciej>
<object>?

[18:42:00.0000] <Philip`>
The first three are in span, div, object, input, select, textarea, button, table

[18:43:00.0000] <Philip`>
datapagesize is in table

[18:48:00.0000] <Hixie>
IE supports 'datasrc', 'datafld', 'dataformatas' and 'datapagesize'

[19:00:00.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%5B%26%23xd840%3B%26%23xdc00%3B%5D

[19:01:00.0000] <Hixie>
how sad

[19:01:01.0000] <othermaciej>
what do they do?

[19:02:00.0000] <Hixie>
all browsers except the latest firefox seem to treat &#xd840;&#xdc00; as U+20000

[19:03:00.0000] <jruderman>
mmm, surrogates

[19:05:00.0000] <Hixie>
dunno what to do about this

[19:06:00.0000] <Hixie>
i guess it's unlikely to be a compat problem

[19:06:01.0000] <Hixie>
i'll just make firefox3's behaviour the spec

[19:08:00.0000] <jruderman>
thanks, how nice of you :)

[19:08:01.0000] <othermaciej>
what's wrong with the all other browser behavior?

[19:08:02.0000] <othermaciej>
I'm guessing that's separate NCRs for the two parts of a surrogate pair for a single char?

[19:09:00.0000] <Hixie>
yeah

[19:10:00.0000] <Hixie>
actually the spec already requires this

[19:13:00.0000] <Hixie>
wtf are High Private Use Surrogates

[19:41:00.0000] <Lachy>
Hey Hixie, while you're looking at unicode stuff, I made a test page to test the upper/lowercasing algorithms.  It seems that browsers get it wrong sometimes (though, my test could be wrong as well)

[19:42:00.0000] <Lachy>
http://lachy.id.au/temp/Unicode/case.html (it may take a while to load, XHR has to load a 1MB unicode data file)

[19:44:00.0000] <Hixie>
Lachy: i'm not really looking at unicode stuff, i'm just going down through the e-mail pile

[19:44:01.0000] <Lachy>
just ignore all the results for chars above U+10000, there's a limitation with JS

[19:44:02.0000] <Hixie>
happened to get to an e-mail of someone complaining about surrogates

[19:44:03.0000] <Lachy>
ok

[19:45:00.0000] <Hixie>
wow, firefox sucks on that test

[19:46:00.0000] <Lachy>
woah, Opera doesn't render the table properly

[19:51:00.0000] <Hixie>
hsivonen?

[19:52:00.0000] <Hixie>
hsivonen requested that we drop spaces that are around the <html> element, because XML drops them

[19:52:01.0000] <Hixie>
and he was concerned about round-tripping HTML5-XHTML5-HTML5

[19:52:02.0000] <Hixie>
but dropping them makes the round-tripping through _HTML5_ much worse

[19:53:00.0000] <Lachy>
why?

[19:53:01.0000] <Hixie>
e.g.  "<!-- --> <!DOCTYPE HTML> <html>...</html> <!-- -->" becomes "<!-- --><!DOCTYPE HTML><html>... </html><!-- -->"

[19:53:02.0000] <Hixie>
(in particular, imagine those as newlines)

[19:56:00.0000] <Hixie>
well

[19:56:01.0000] <Hixie>
based on my tests with the live dom inspector

[19:56:02.0000] <Hixie>
i'm the only who cares!

[19:56:03.0000] <Lachy>
that depends on how you serialise it, not whether those spaces are presentin the DOM

[19:57:00.0000] <Lachy>
and since the DOM doesn't retain text nodes outside the root anyway

[19:57:01.0000] <Hixie>
it used to :-)

[19:57:02.0000] <Hixie>
/me checks in a change to drop whitespace outside the DOM

[19:57:03.0000] <Lachy>
it used to in the spec, or in some implementation?

[19:58:00.0000] <Hixie>
spec

[20:16:00.0000] <Hixie>
wow, well here's a solid argument like none before it:

[20:16:01.0000] <Hixie>
Deprecating the embed element would make the standard more consistent and

[20:16:02.0000] <Hixie>
would make me feel better about the standard eventually.

[20:16:03.0000] <Hixie>
Not that I feel bad right now, that is.

[21:37:00.0000] <Hixie>
othermaciej, you might need to do another IANAL-but e-mail, this time explaining trademark law... :-)

[21:44:00.0000] <othermaciej>
Hixie: the legal standing of the W3C's trademark is so many steps removed from relevance to the discussion...

[21:44:01.0000] <othermaciej>
Hixie: but I'll explain it if I have to

[21:44:02.0000] <Hixie>
i was mostly kidding :-)

[21:45:00.0000] <Hixie>
they lost that trademark long ago, when they didn't sue me for calling the web apps spec's language "html5" and "xhtml5"

[21:47:00.0000] <othermaciej>
they don't claim a trademark on HTML

[21:47:01.0000] <othermaciej>
and yes, I doubt most of the language trademarks on that page would hold up

[21:47:02.0000] <othermaciej>
CSS, DOM, SVG, XHTML, no one cites their trademark when referring to those

[21:47:03.0000] <Hixie>
yeah, they used to claim the trademark but stopped around 2001

[21:47:04.0000] <Hixie>
iirc

[21:48:00.0000] <Hixie>
probably had a lawyer laugh at them :-)

[22:06:00.0000] <Lachy>
Hixie, regarding your last post about versioning on public-html, I wouldn't call consistency with previous HTML versions a valid reason for versioning at all because it assumes that consistency actually achieves something useful

[22:07:00.0000] <Hixie>
it was consistency with future versions that was being suggested i think

[22:08:00.0000] <Hixie>
but as a general rule, it's good to give the "other side" in a debate the impression of having won something... admitting defeat on an irrelevant and worthless argument is a good way to win the argument overall.

[22:08:01.0000] <Lachy>
then it's even less valid, because the assumption is the future revisions will need to add versioning

[22:08:02.0000] <Lachy>
ok

[22:08:03.0000] <Hixie>
i agree that it's a ridiculuous argument. that's why's it a good one to agree about.

[22:08:04.0000] <Hixie>
:-)

[22:09:00.0000] <Hixie>
(that's one reason to never give the other side _all_ your arguments -- only to give the strong ones -- because then they are forced to either disagree with everything, or to give you a strong argument if they do what i just described)

[22:10:00.0000] <Hixie>
(and if they disagree with everything, then they look like they're being unreasonable, and then the clueless people who come in and try to be "reasonable" by giving "compromises" invariably take one of the things you said as a way to give you an argument

[22:10:01.0000] <Hixie>
which is then a strong argument, since you didn't give them the weak ones to pick from)

[22:10:02.0000] <Lachy>
/me is confused

[22:45:00.0000] <Hixie>
so... someone pointed out that "character entity reference" was being misused in the HTML5 spec

[22:45:01.0000] <Hixie>
since there's no DTD or anything

[22:45:02.0000] <Hixie>
what should we call them instead?

[22:54:00.0000] <Lachy>
just call them character references

[22:55:00.0000] <Hixie>
and drop the word "entity"?

[22:55:01.0000] <Hixie>
hmm, that could work

[22:56:00.0000] <Lachy>
the problem is calling &#nnnn; and &#xnnnn; entities is wrong. In SGML and XML, &foo; is an general entity ref. &amp;, for example, is commonly called a character entity ref because it only contains 1 char

[22:57:00.0000] <Lachy>
but officially, there is no such thing as a character entity ref in SGML or XML

[22:57:01.0000] <Hixie>
yeah, mike explained that on the list

[22:57:02.0000] <Lachy>
ok

[22:57:03.0000] <Hixie>
there's a numeric character reference and a character entity reference

[22:57:04.0000] <Lachy>
yeah

[22:58:00.0000] <Lachy>
I recommend only using entity when you need to distinguish between &#...; and &foo;

[22:59:00.0000] <Hixie>
well, we'll see what replies i get to the thread

[23:53:00.0000] <Hixie>
ok how the hell do i do this

[23:53:01.0000] <Hixie>
complete this sentence:

[23:53:02.0000] <Hixie>
<p>The contents of CDATA and RCDATA elements must...

[23:54:00.0000] <Hixie>
...in a way that defines that they can contain pairs of <!-- and --> (which can overlap) and that </endtags> that aren't escaped by those pairs are not ok

[23:58:00.0000] <jruderman>
why does it have to be a sentence, rather than a paragraph, and why does it have to start that way?

[23:58:01.0000] <Hixie>
it doesn't. in fact i'm up to three paragraphs so far.

[23:59:00.0000] <Hixie>
i was just phrasing it as a quiz show question :-)

[00:01:00.0000] <karlUshi>
just for the record. Hixie didn't decide to call it html5

[00:01:01.0000] <karlUshi>
in fact it has been suggested by someone else

[00:01:02.0000] <karlUshi>
:) anyway

[00:01:03.0000] <karlUshi>
childish

[00:02:00.0000] <Hixie>
?

[00:02:01.0000] <Hixie>
didn't decide to call what html5?

[00:03:00.0000] <karlUshi>
webapps 1.0

[00:03:01.0000] <Hixie>
the whatwg language was called html5 before the whatwg was announced

[00:03:02.0000] <Hixie>
in fact howcome suggested it to me when we had dinner after my interview at opera back in 2003

[00:03:03.0000] <Hixie>
or 2002

[00:03:04.0000] <Hixie>
2003 i think

[00:03:05.0000] <Hixie>
which was about a year before we started web apps 1.0

[00:05:00.0000] <karlUshi>
/me will abstain to talk :) for the benefits of everyone.

[00:05:01.0000] <Hixie>
the spec itself was called "web apps 1.0" (as opposed to "html5" as it is now) for various political reasons, but it claimed to define html5 since the very start, as far as i recall

[00:11:00.0000] <jruderman>
Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=385434

[00:11:01.0000] <Hixie>
interesting idea

[00:24:00.0000] <othermaciej>
that is a good idea

[00:24:01.0000] <othermaciej>
especially with the fragment ID being used to simulate "AJAX history"

[00:24:02.0000] <Hixie>
woot, the HTML parser folder is empty!

[00:24:03.0000] <Hixie>
now for the input-for-whatwg-html-parsing-rules-encoding folder.

[00:25:00.0000] <Hixie>
maybe i should go home first

[00:25:01.0000] <Lachy>
I just checked in a whole bunch of new and revised examples. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=utf-8

[00:25:02.0000] <othermaciej>
that would be advisable yes

[00:25:03.0000] <othermaciej>
I am happy with the way HTML5 is coming along

[00:25:04.0000] <Hixie>
glad to hear it

[00:25:05.0000] <othermaciej>
(though I have only been able to pay ~3% of my attention to it the past few weeks)

[00:29:00.0000] <Hixie>
bbl

[01:12:00.0000] <Hixie>
hsivonen: yt? i was wondering if you had any opinions on whether we should continue the way we have for the encoding detection or if we should require the algorithm you suggested back in march last year where we basically do the encoding detection in the main parser and then rewind if necessary

[01:15:00.0000] <Lachy>
Hixie, do you mean this one? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-March/005989.html

[01:17:00.0000] <Hixie>
yeah

[01:17:01.0000] <Hixie>
it

[01:17:02.0000] <Hixie>
er

[01:17:03.0000] <Hixie>
it's tempting to just use that, but it's more complicated to implement

[01:17:04.0000] <Hixie>
also i'm not really sure how you would handle event handlers and stuff like that

[01:18:00.0000] <Hixie>
i mean, we'd need to raise the REWIND flag in a _lot_ of places

[01:18:01.0000] <othermaciej>
what would REWIND do? reparse from scratch?

[01:19:00.0000] <Hixie>
yeah

[01:19:01.0000] <Hixie>
see the algorithm proposed in the e-mail above

[01:19:02.0000] <othermaciej>
/me reads

[01:19:03.0000] <Hixie>
how does safari actually implement encoding detection?

[01:21:00.0000] <othermaciej>
it's changed semi-recently so my knowledge of it may be out of date

[01:22:00.0000] <Hixie>
what source file is it in?

[01:23:00.0000] <othermaciej>
(reading the algorithm)

[01:23:01.0000] <othermaciej>
it's in WebCore/loader/TextResourceDecoder.cpp

[01:24:00.0000] <othermaciej>
(mostly)

[01:25:00.0000] <othermaciej>
One part of hsivonen's algorithm definitely needs changing

[01:25:01.0000] <othermaciej>
"If the tentative encoding name does not identify a rough ASCII  

[01:25:02.0000] <othermaciej>
superset supported by the UA, emit a hard parse error and perform  

[01:25:03.0000] <othermaciej>
implementation-specific heuristics."

[01:25:04.0000] <othermaciej>
UTF-16 needs to be handled as UTF-8 in such cases for web compatibility

[01:26:00.0000] <othermaciej>
I guess you could call that an implementation-specific heuristic

[01:26:01.0000] <Hixie>
good to know

[01:26:02.0000] <othermaciej>
I know we discovered at some point that Firefox appears to do a full parse and rewind

[01:27:00.0000] <othermaciej>
we used to have a dumbed-down preparse, and I think we still do, but we are considering changing

[01:27:01.0000] <othermaciej>
or maybe doing the preparse but also rewinding parsing if we hit a <meta charset>

[01:27:02.0000] <Lachy>
yes, regardless of how big the file is, a  <meta charset=""> anywhere will cause a reparse if the declared encoding is incompatible with Win 1252

[01:27:03.0000] <Lachy>
(or something like that)

[01:29:00.0000] <Hixie>
but is the reparse done despite scripts having run?

[01:29:01.0000] <Lachy>
yes

[01:29:02.0000] <Hixie>
lovely

[01:31:00.0000] <Hixie>
sounds like what we want to do is have an optional dumb preparse, then if that was skipped or if it didn't find an encoding, default to some encoding and start parsing, and if you hit a charset declaration that disagrees with the current one (notwithstanding UTF-16) then you start over (only doing that for the first charset seen)

[01:32:00.0000] <Lachy>
hmm.  I can't get FF to execute the script twice, but IE will

[01:32:01.0000] <Hixie>
really?

[01:32:02.0000] <Hixie>
how are you testing?

[01:34:00.0000] <Hixie>
also i guess you would only reparse if one of the bytes you saw was incomptaible

[01:34:01.0000] <Lachy>
yes

[01:34:02.0000] <Hixie>
no point reparsing if you've not seen a disagreeable byte, as it were

[01:34:03.0000] <Lachy>
<!DOCTYPE html>©<script>alert("Hi");</script><meta charset="ISO-8859-2"> (save as ISO-8859-1)

[01:35:00.0000] <Lachy>
also, IE remembers the last encoding it used for the file, so it won't do a reparse if you hit reload

[01:35:01.0000] <Hixie>
does the byte in mozilla when you do that look like (c)?

[01:36:00.0000] <Lachy>
no, it interprets it as 8859-2: Š

[01:36:01.0000] <Hixie>
without running the script twice? it must have some sort of dumb preparser

[01:36:02.0000] <Hixie>
try sticking 2k of text before the byte

[01:36:03.0000] <Hixie>
i saw something about a 2k buffer when i was just browsing the mozilla code a few minutes ago

[01:38:00.0000] <Lachy>
yes, it reparsed it that time

[01:39:00.0000] <Hixie>
does it also do it if you don't have the (c) byte?

[01:41:00.0000] <Lachy>
yes

[01:41:01.0000] <Hixie>
interesting

[01:42:00.0000] <Hixie>
thanks

[01:42:01.0000] <Hixie>
i think this will work pretty well

[01:42:02.0000] <Hixie>
it's compatible with what browsers do, and allows for interesting optimisations

[01:43:00.0000] <Hixie>
this = what i proposed above, slightly tweaked to take into account what you've found out

[01:43:01.0000] <Lachy>
I prefer the algorithm in the spec already since it's much saner and easier to implement

[01:44:00.0000] <Lachy>
would hsivonen's algorithm handle cases like <script>document.write("<meta charset='ISO-8859-2'>");</script>?

[01:50:00.0000] <Hixie>
yeah, we would keep the algorithm in the spec

[01:50:01.0000] <Hixie>
we'd just add that if you hit a <meta> later, you reparse in certain cases

[01:50:02.0000] <Hixie>
i don't propose using henri's idea

[01:51:00.0000] <Hixie>
my notes are as follows:

[01:51:01.0000] <Hixie>
 have an optional dumb preparse, allow it to use more than 512 bytes

[01:51:02.0000] <Hixie>
  if it found an encoding, let "tentative" be that encoding

[01:51:03.0000] <Hixie>
  if it was skipped, or if it didn't find an encoding,

[01:51:04.0000] <Hixie>
    let "tentative" be the last encoding used for this page,

[01:51:05.0000] <Hixie>
    or some other default

[01:51:06.0000] <Hixie>
 begin parsing using "tentative" as the encoding

[01:51:07.0000] <Hixie>
  if you hit a <meta> tag that defines the encoding

[01:51:08.0000] <Hixie>
    which disagrees with the current,

[01:51:09.0000] <Hixie>
    reparse with that encoding (except treat "UTF-16" as "UTF-8")

[01:51:10.0000] <Hixie>
    optionally: if no bytes that differ between the encodings has yet been

[01:51:11.0000] <Hixie>
      found, just replace the decoder in place and don't reparse

[01:52:00.0000] <Hixie>
    to reparse, use the session history things that save state

[01:53:00.0000] <Hixie>
i wonder if people realise that a version="" attribute won't help XHTML2 since the DOM node interfaces are decided by tagname and namespace, unaffected by attributes

[01:54:00.0000] <Hixie>
unless they want to play with HTMLHtmlElement as well

[01:55:00.0000] <othermaciej>
I would be more worried about this if there were any sign of anyone wanting to implement XHTML2

[01:56:00.0000] <Hixie>
indeed

[01:56:01.0000] <zcorpan>
Hixie: is it possible to build a dom with "=" as attribute name?

[01:57:00.0000] <Hixie>
it is in HTML5, sure

[01:57:01.0000] <Hixie>
<x =>

[01:57:02.0000] <zcorpan>
but not with dom apis like setAttribute?

[01:58:00.0000] <Hixie>
seems browsers raise an exception for that

[01:59:00.0000] <zcorpan>
ok

[02:03:00.0000] <zcorpan>
Hixie: i know some entities require a semi-colon even in attributes -- that's what i wrote ("a third column that says which entities always require a semi-colon", i.e. both in attributes and in content)

[02:03:01.0000] <Lachy>
for <x =>, couldn't it just drop the attribute entirely?

[02:04:00.0000] <Lachy>
actually, for that IE creates an attribute with no name and no value

[02:05:00.0000] <Lachy>
FF drops it

[02:05:01.0000] <zcorpan>
Lachy: old news ;)

[02:05:02.0000] <Hixie>
zcorpan: ah ok

[02:16:00.0000] <zcorpan>
Hixie: although what is specced now has the same result as what i proposed, so the spec is fine

[02:19:00.0000] <zcorpan>
Hixie: btw, the innerHTML algorithm is used when scripting is disabled... iirc Genshi implements the innerHTML algorithm for serializing to html

[02:27:00.0000] <Hixie>
the html fragment serialising algorithm?

[02:27:01.0000] <Hixie>
hm

[02:27:02.0000] <Hixie>
wonder if that works well

[02:28:00.0000] <Hixie>
might be a problem if you have <noscript>&lt/noscript> ... </noscript> in a document

[02:34:00.0000] <zcorpan>
it probably doesn't, but i wouldn't be surprised if more people implement the fragment serialising algorithm for no scripting contexts... so if the algorithm took it into account then it might lead to less buggy tools

[02:37:00.0000] <Hixie>
yeah

[02:37:01.0000] <Hixie>
might just need two modes

[03:24:00.0000] <Hixie>
/me waits for othermaciej to explain that having "html|*:not([version=2]) " at the start of every selector in the UA stylesheet isn't going to scale well

[03:24:01.0000] <othermaciej>
Hixie: I hope that's a joke

[03:25:00.0000] <Hixie>
i take it you haven't seen the reply to your last mail

[03:25:01.0000] <othermaciej>
/me facepalms

[03:25:02.0000] <Hixie>
it was put quite that way

[03:26:00.0000] <mpt>
You're almost making me wish I was subscribed to the html-wg mailing list

[03:27:00.0000] <mpt>
but doubtless there are more efficient sources of humor

[03:28:00.0000] <Hixie>
yeah, public-xhtml2 has a much higher humor-per-mail quotient

[03:28:01.0000] <Hixie>
oops, did i say that out loud

[03:32:00.0000] <annevk>
<meta http-equiv> requirements are a bit odd

[03:32:01.0000] <Hixie>
yeah i wondered if i should allow <meta charset> in there too

[03:32:02.0000] <Hixie>
but that seemed dangerous

[03:32:03.0000] <annevk>
"it must be either in a <code>head</code> element" "Otherwise, it must be in a <code>head</code> element."

[03:32:04.0000] <annevk>
is what I meant

[03:33:00.0000] <Hixie>
hm?

[03:33:01.0000] <Hixie>
/me looks

[03:34:00.0000] <Hixie>
what's the problem?

[03:34:01.0000] <annevk>
it says the same thing twice?

[03:34:02.0000] <Hixie>
oh, i see, the "otherwise" clause is unclear

[03:34:03.0000] <Hixie>
i'll change it to just "if it doesn't have..."

[03:35:00.0000] <othermaciej>
I pointed Jirka to the mozilla and webkit source code

[03:35:01.0000] <othermaciej>
in case he'd like to make comments about what is doable in browsers that are actually informed

[03:36:00.0000] <Hixie>
i'm sure that will go down well

[03:37:00.0000] <othermaciej>
I also gave a more concrete example where a version attribute cannot possibly help resolve a namespace clash

[03:38:00.0000] <Hixie>
annevk: fixed

[03:38:01.0000] <zcorpan>
Hixie: i can't think of use-cases for <noscript><meta name>, however i don't see a good reason to disallow it either

[03:39:00.0000] <Hixie>
othermaciej: nice example

[03:39:01.0000] <Hixie>
zcorpan: shouldn't the metadata not change based on whether scripting is enabled?

[03:39:02.0000] <zcorpan>
dunno

[03:39:03.0000] <zcorpan>
perhaps

[03:40:00.0000] <Hixie>
if you feel it should change, send mail, it wouldn't take much to make me change the spec

[03:40:01.0000] <Hixie>
i agree with your mail about entities

[03:40:02.0000] <Hixie>
i wonder what the people who care will say

[03:46:00.0000] <zcorpan>
Hixie: why are the <!-- and --> in (R)CDATA allowed to overlap when they are not allowed to overlap in PCDATA? (i.e. from a conformance POV)

[03:48:00.0000] <annevk>
we're seriously debating <html version=> now?

[03:48:01.0000] <annevk>
wow

[03:48:02.0000] <othermaciej>
annevk: mainly whether it would miraculously allow XHTML5 and XHTML2 to share the same namespace

[03:49:00.0000] <annevk>
http://www.itwriting.com/blog/?p=257 is interesting

[03:50:00.0000] <zcorpan>
xhtml2 already has the version attribute. if they think it's enough to trigger different handling of xhtml2, then all is well already.

[03:54:00.0000] <Hixie>
sweet! only 371 days to go!

[03:54:01.0000] <Hixie>
http://www.apple.com/trailers/disney/walle/hd/

[03:54:02.0000] <Hixie>
/me does a little dance

[03:55:00.0000] <othermaciej>
so you're not as interested in ratatouille?

[04:07:00.0000] <annevk>
is 0x0D equal to CR?

[04:10:00.0000] <othermaciej>
yes

[04:10:01.0000] <othermaciej>
(man ascii)

[04:10:02.0000] <Hixie>
othermaciej: i'm ecstatic about ratatouille. But I knew the release date last year. http://ln.hixie.ch/?start=1149918352&count=1

[04:11:00.0000] <Hixie>
how can you not know that 0x0D / 13 is CR :-P

[04:11:01.0000] <othermaciej>
so you like to keep your countdowns one ahead?

[04:11:02.0000] <Hixie>
othermaciej: i just countdown as far as i can :-)

[04:11:03.0000] <Hixie>
othermaciej: more things to be excited about that way

[04:12:00.0000] <Hixie>
amusingly, june 29th is the release date of 3 things, two of which steve-jobs-related, and two of which movies

[04:12:01.0000] <Hixie>
only one of which i care about

[04:12:02.0000] <annevk>
so why does 0x0D become LF now?

[04:13:00.0000] <annevk>
/me thought browsers did not fix it up

[04:13:01.0000] <Hixie>
0x0D wher?

[04:13:02.0000] <Hixie>
where, even

[04:13:03.0000] <annevk>
as character reference

[04:14:00.0000] <Hixie>
opera doesn't fix it up, ie drops it altogether, firefox and safari fix it up, css expects it to be fixed up

[04:14:01.0000] <Hixie>
(iirc)

[04:14:02.0000] <annevk>
k

[04:17:00.0000] <Hixie>
i have to say it amazes me that pixar can set release dates more than a year ahead

[04:17:01.0000] <Hixie>
and hit them, year after year

[04:18:00.0000] <Hixie>
i'm lucky if i can set release dates a week ahead, and i'm just one person with one little set of tasks

[04:24:00.0000] <annevk>
news just in: readyState = 2 -> HEADERS_RECEIVED

[04:24:01.0000] <annevk>
or does someone have a better name?

[04:26:00.0000] <Jero>
and HEADERS_RECEIVED is an array of all the headers the object received?

[04:26:01.0000] <annevk>
it's a state

[04:27:00.0000] <Hixie>
what was it before?

[04:27:01.0000] <Jero>
oh ok, i see what you mean now

[04:27:02.0000] <Jero>
sorry for the misunderstanding

[04:27:03.0000] <annevk>
currently we have UNSENT, OPEN, SENT, LOADING, DONE

[04:27:04.0000] <annevk>
SENT -> HEADERS_RECEIVED

[04:28:00.0000] <annevk>
but it would be nice if it was a little bit shorter

[04:28:01.0000] <Hixie>
what did i use for the media elements?

[04:29:00.0000] <annevk>
FRAME_AVAILABLE or something? or PLAY_THROUGH

[04:29:01.0000] <annevk>
but that's slightly different

[04:29:02.0000] <Hixie>
i thought i had one for headers only

[04:30:00.0000] <Hixie>
LOADED_METADATA

[04:30:01.0000] <Hixie>
i have EMPTY, (no equivalent for OPEN), LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED

[04:30:02.0000] <annevk>
ok, UNSENT, OPEN, LOADED_METADATA, LOADING, DONE

[04:31:00.0000] <annevk>
mjs suggested that EMPTY was not quite the same for XHR or so iirc

[04:31:01.0000] <annevk>
and DONE is there because it's also readyState = 4 when the request failed

[04:31:02.0000] <Hixie>
the problem with XHR having LOADED_METADATA, LOADING is that it's the opposite order

[04:31:03.0000] <Hixie>
which would be confusing

[04:31:04.0000] <annevk>
yeah, that too

[04:31:05.0000] <Hixie>
oh well

[04:32:00.0000] <annevk>
LOADED_HEADERS maybe?

[04:32:01.0000] <Hixie>
similar though, with a LOADING after a LOADED, bit confusing

[04:32:02.0000] <Hixie>
how about just HEADERS?

[04:33:00.0000] <Hixie>
UNSENT, OPEN, HEADERS, LOADING, DONE

[04:33:01.0000] <annevk>
sure

[04:33:02.0000] <Hixie>
not a verb, i guess

[04:33:03.0000] <annevk>
hmm

[04:33:04.0000] <Hixie>
or adjective

[04:33:05.0000] <Hixie>
or whatever those are

[04:33:06.0000] <annevk>
HEADERS_IN

[04:34:00.0000] <Hixie>
HEADERS_RECEIVED and HEADERS are my favourites so far

[04:38:00.0000] <Philip`>
About serialising: The HTML5 spec splitter uses the innerHTML fragment serialising algorithm too (or at least the version of the algorithm from ages ago)

[04:43:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-html/2007Jun/0543.html has that guy even remotely considered DOM interfaces?

[04:46:00.0000] <annevk>
besides the fact that the charter mentions to align more with browsers as opposed to diverging from them in weird ways

[05:33:00.0000] <Lachy>
Hixie, what is ratatouille and why are you so ecstatic about it?

[05:33:01.0000] <Lachy>
/me is downloading the trailer for Wall-E

[05:34:00.0000] <annevk>
hixie &heart; pixar

[05:34:01.0000] <Lachy>
is there a trailer for ratatouille somewhere?

[05:35:00.0000] <Lachy>
found it

[05:57:00.0000] <Philip`>
/me wonders if it's cruel to write tests that require globalCompositeOperation = darker to be unrecognised

[05:58:00.0000] <annevk>
weren't there proposals to keep that in?

[05:59:00.0000] <Philip`>
Yes, but it's not in the list at the moment so it mustn't be supported

[05:59:01.0000] <Philip`>
/me also checks for globalCompositeOperation=over being unrecognised, just so that Firefox fails

[06:00:00.0000] <annevk>
I suppose

[06:00:01.0000] <Philip`>
/me checks if anyone else is secretly supporting non-standard values

[06:08:00.0000] <Philip`>
Oh, FF does 'clear' too

[06:09:00.0000] <Philip`>
and WebKit does 'clear' and 'highlight'

[06:18:00.0000] <Philip`>
Hmm, interesting that 'clear' is supported in two of the three main browsersa, and it's the only Porter-Duff operator missing from the spec... I can't think of any possible use cases at all, though

[06:19:00.0000] <annevk>
maybe it was easy to implement?

[06:21:00.0000] <Philip`>
"CANVAS_OP_TO_CAIRO_OP("clear", CLEAR)" - the implementation in Gecko doesn't look that tricky

[06:24:00.0000] <Philip`>
and the entirety of WebKit's 'clear' implementation is:

[06:24:01.0000] <Philip`>
    "clear",

[06:24:02.0000] <Philip`>
which isn't too tricky either

[06:26:00.0000] <annevk>
what does it do?

[06:27:00.0000] <Philip`>
It takes the source image, and the destination image, and then discards both of them and outputs transparent black

[06:28:00.0000] <Philip`>
I believe you can get exactly the same effect by doing "globalAlpha = 0; globalCompositeOperation = 'copy'"

[06:29:00.0000] <Philip`>
(Ah, looks like Opera is nice and doesn't support anything non-standard except for "darker")

[06:32:00.0000] <annevk>
we're a likably product :p

[06:33:00.0000] <Philip`>
Opera does incorrectly accept strings like "source-over\0", though :-p

[06:35:00.0000] <annevk>
I suppose we strip \0 before it's passed...

[06:35:01.0000] <annevk>
hmm

[06:36:00.0000] <Philip`>
If I remember correctly, everything after the \0 gets stripped off too

[07:13:00.0000] <Philip`>
/me wonders what makes Opera dislike <canvas>x<canvas>y</canvas>z</canvas>

[07:22:00.0000] <Dashiva>
Would that ever be useful fallback?

[07:25:00.0000] <Philip`>
I'm not sure about 'useful', but it could be used - if you have non-interactive static visual media, and you paint on the inner canvas but not the outer one, then it would use the fallback content for the outer one and would display the inner one

[07:26:00.0000] <Philip`>
but as far as I can see, that's the only situation in which you'd ever see the inner canvas

[07:26:01.0000] <Dashiva>
I don't understand that example, what triggers fallback on the outer one?

[07:27:00.0000] <Philip`>
"In non-interactive, static, visual media, if the canvas element has been previously painted on ... then the canvas element must be treated as embedded content with the current image and size. Otherwise, the element's fallback content must be used instead."

[07:28:00.0000] <Dashiva>
So you'd have to paint on it somewhere else, and then adoptNode or similarly move it to the static media?

[07:30:00.0000] <Philip`>
I think you could just have a script that's run by the static-media UA and does getElementsByTagName('canvas')[1].getContext('2d').fillRect(0, 0, 300, 150) or whatever, in order for it to become "previously painted on"

[07:34:00.0000] <Philip`>
I can't think of any situations at all in which anyone would want to do that, though

[07:35:00.0000] <Philip`>
(but it'd be nice if it worked correctly anyway :-) )

[07:35:01.0000] <Dashiva>
Yeah, I have problems imagining "previously" combined with "static, non-interactive"

[07:36:00.0000] <Philip`>
As I understand it, it's the media that's static and non-interactive - you could have a real web browser that loads the page and runs scripts, and then renders the result to a (static, non-interactive) PDF file

[07:37:00.0000] <Dashiva>
Aha

[07:38:00.0000] <Dashiva>
That at least makes sense.

[07:44:00.0000] <annevk>
so what exactly do we do for nested <canvas> elements that is not expected?

[07:45:00.0000] <annevk>
actually, I believe we have some bugs in the way we parse <canvas> elements

[07:45:01.0000] <annevk>
"bugs" as parsing for HTML was not really defined until HTML5 came along

[07:46:00.0000] <annevk>
(Entity handling in html5lib is now per the specification.)

[07:46:01.0000] <annevk>
(Except for some special character range, fwiw.)

[07:47:00.0000] <Philip`>
That case gives a (empty) canvas element followed by a "y", when it should give one containing "x (canvas y) z" - presumbly it just looks for the first </canvas>, instead of actually parsing the content

[07:48:00.0000] <annevk>
followed by a "z" you mean?

[07:48:01.0000] <Philip`>
At least Opera is no more broken than IE/excanvas, which just looks for the first "/canvas" element :-)

[07:48:02.0000] <Philip`>
Oops, yes

[07:49:00.0000] <annevk>
we parse it similar to iframe I think

[07:49:01.0000] <annevk>
well, those type of elements

[07:50:00.0000] <Philip`>
Ah, okay - looks like it's handled like iframe, when (I think) it ought to be handled like object instead

[07:50:01.0000] <annevk>
i agree, we have some bug report on the matter

[07:51:00.0000] <annevk>
well, prolly not <object> exactly as <object> is quite hairy too iirc

[08:32:00.0000] <Lachy>
Hixie, I just watched the trailers and preview for ratatouille.  It looks like an awesome movie

[09:38:00.0000] <Lachy>
I have the selectors api naming narrowed down to 7 pairs of names, having written detailed justification for rejecting the other ~30 :-)

[09:43:00.0000] <Dashiva>
Lachy: In other words, all the good ones are gone :)

[09:43:01.0000] <Lachy>
no, the crap ones have been rejected

[09:44:00.0000] <Lachy>
These are the remaining choices:

[09:44:01.0000] <Lachy>
matchSingle() matchAll()

[09:44:02.0000] <Lachy>
matchOne() matchAll()

[09:44:03.0000] <Lachy>
getElement() getElementList()

[09:44:04.0000] <Lachy>
getElement() getElements()

[09:44:05.0000] <Lachy>
selectElement() selectElementList()

[09:44:06.0000] <Lachy>
selectOneElement() selectAllElements()

[09:44:07.0000] <Lachy>
chooseOne() chooseAll()

[09:46:00.0000] <Lachy>
anyone have any preferences from that list?

[09:48:00.0000] <Philip`>
Is selectElement+selectAllElements not a choice?

[09:50:00.0000] <Lachy>
Philip`: that's a close call.  I had to reject some simply because they were very similar to other options that were considered equal, and I felt the slight inconsistency between the names was good reason at that point

[09:51:00.0000] <Lachy>
so it was only barely rejected

[09:55:00.0000] <Philip`>
I guess I kind of like 'select' since it looks easy to remember when I forget the exact name but know I want to find that function that's like CSS selectors; and 'selectOneElement' sounds unnecessarily verbose compared to 'selectElement'; and 'selectElementList' is vague whereas 'selectAllElements' is self-descriptive

[09:55:01.0000] <Philip`>
But I don't have any strong feelings :-)

[09:55:02.0000] <Lachy>
oh, good point

[09:56:00.0000] <Lachy>
ok, I'll switch selectOneElement for selectElement

[10:05:00.0000] <hallvors>
IMO 'selectElementList' is clearer than 'selectAllElements', I'd assume the latter did the same as getElementsByTagName('*')

[10:10:00.0000] <Philip`>
hallvors: But you wouldn't normally see just the function name by itself - you'd see something like "selectAllElements('h1')" or "selectAllElements('[class|="shadow"]')", and then it'd be obvious that it's not just selecting all the elements in the document

[10:11:00.0000] <Lachy>
the other option is selectElement() and selectElements(), but I think they look too similar and make editing and reviiewing more difficult

[10:12:00.0000] <Lachy>
do you consider selectElement to be better than getElement?

[10:12:01.0000] <Dashiva>
Has overloading (e.g. function selectElement(selector, selectall=true)) been considered and rejected?

[10:13:00.0000] <Philip`>
(Assuming that [class|="shadow"] thing actually works, I guess that'd be nice for the Unobtrusive JavaScript people so they can just add class="shadow-25x25" and easily scriptise things)

[10:13:01.0000] <Lachy>
Dashiva: yes.  That would require the method to change its return type based on a parameter, which isn't good

[10:13:02.0000] <Dashiva>
Ah right, JS match returns array in both cases

[10:13:03.0000] <Lachy>
document.evaluate() does that for DOM3 XPath, but I don't think that's particularly good design

[10:14:00.0000] <Lachy>
yeah, selectElement() would return a single element, selectAllElements() would return a static node list

[10:14:01.0000] <annevk>
hallvors on IRC, yay!

[10:14:02.0000] <Philip`>
getElement sounds vague again to me - with something like getElementById or (once you've heard of it at least once) selectElement, the name tells you how it decides which element you want, which makes it easier to remember

[10:15:00.0000] <Dashiva>
I agree, getSomething is too vague without a BySomething

[10:15:01.0000] <Lachy>
that rationale for getElement is that it's like a superset of all existing getElementBy* methods

[10:16:00.0000] <Dashiva>
But since it doesn't let you get an id without prefixing #, it's not a true superset

[10:16:01.0000] <Lachy>
a superset in functionality, not in syntax

[10:17:00.0000] <Philip`>
Will people still use the old getElementBy* functions? It seems slightly nicer to still say getElementById(variablething) rather than getElement('#'+variablething)

[10:18:00.0000] <Philip`>
(particularly if you have IDs with spaces in them)

[10:18:01.0000] <annevk>
IDs with spaces are non-conforming

[10:19:00.0000] <Philip`>
People might still use them, and be unhappy that it gets mangled by the CSS-selector parser when all they want is an exact string match

[10:19:01.0000] <hallvors>
Philip`: good point, I like the name with some more  context

[10:19:02.0000] <Lachy>
IDs with spaces can be escaped as #foo\ bar

[10:20:00.0000] <Lachy>
hallvors: which name do you like?

[10:20:01.0000] <Philip`>
Lachy: But then you'd have to write a function to do CSS escaping, which is probably non-trivial and will probably be done wrong, and it's much safer to stick with getElementById when you just want to match IDs

[10:21:00.0000] <Lachy>
oh, does gEBId allow spaces?

[10:21:01.0000] <Lachy>
HTML doesn't allow spaces

[10:21:02.0000] <Lachy>
I don't know of any language that does

[10:21:03.0000] <hallvors>
At first I preferred selectElementList over selectAllElements, but the examples changed my mind.

[10:22:00.0000] <hallvors>
so now I think selectAllElement is better of the two..

[10:22:01.0000] <Lachy>
do you think it's better than the other 5 alternatives as well?

[10:24:00.0000] <Philip`>
Lachy: id="x y" ... getElementById('x y') seems to work perfectly well in browsers, which is usually much more interesting than whether it's meant to be allowed :-)

[10:24:01.0000] <Dashiva>
I don't like match because it crosses over into regexp language. choose doesn't really fit. Among the rest, I prefer select over get, because it is about selectors after all.

[10:24:02.0000] <annevk>
getElement("#x\u20y") will also work likely

[10:24:03.0000] <Lachy>
I was more concerned about whether gEBId() threw an exception, than the validity if the syntax

[10:25:00.0000] <annevk>
given that \u20 is the correct escape

[10:25:01.0000] <Philip`>
Lachy: Ah, okay - seems to work happily with no exceptions

[10:25:02.0000] <Philip`>
annevk: Wouldn't that have to be getElement("#x\\u20y") ?

[10:25:03.0000] <annevk>
Philip`, btw, any chance you can e-mail me with the changes I missed in html4-differences and maybe also with the script you used?

[10:25:04.0000] <Lachy>
annevk: \u20 is a JS escape for a space char, that won't be seen by the selector parsor

[10:26:00.0000] <Lachy>
it would be equivalent to "#x y"

[10:26:01.0000] <annevk>
Philip`, yeah, fair enough

[10:27:00.0000] <Philip`>
IE throws exceptions on "x\u20y" because it wants "20y<EOF>" to be a hex string

[10:27:01.0000] <Lachy>
oh, you need \u0020

[10:30:00.0000] <Lachy>
you would actually need to use ("#x\\\u0020y"), though "#x\\ y" is easier

[10:31:00.0000] <Philip`>
annevk: http://krijnhoetmer.nl/irc-logs/html-wg/20070622#l-47 is all the bits I noticed originally that weren't mentioned

[10:31:01.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/htmldiffs.pl is the script, though it's rather ugly and hacked-together and I gave up trying to keep it even vaguely clean when I was half way through

[10:31:02.0000] <Philip`>
(Should I email these links?)

[10:32:00.0000] <annevk>
preferably

[10:32:01.0000] <annevk>
maybe I'll just write a small python script that parses your results page though :)

[10:32:02.0000] <annevk>
and turns it into an HTML table

[10:33:00.0000] <Philip`>
The code in the bottom third of the script that produces the output should be relatively easy to read and modify into a different format, if you ignore the few lines that have too much syntax on them :-)

[10:35:00.0000] <annevk>
whoa, did the real Philip Taylor just post to publib-html? :D

[10:35:01.0000] <annevk>
Philip`, hmm, it's in Perl though

[10:36:00.0000] <Philip`>
The original list of non-mentioned things is probably missing a few bits since I fixed my code, so I'll re-check that this evening and send the list to you

[10:38:00.0000] <Philip`>
I did post, just so I can confuse everyone who doesn't realise there's two people with one name rather than one person with multiple personalities

[10:39:00.0000] <Philip`>
Perl isn't that bad, as long as you skip over the pieces like [@{$attrs4s{$e}||[]}, @{$attrs4t{$e}||[]}] :-p

[10:40:00.0000] <Dashiva>
You mean there are other pieces?

[10:40:01.0000] <Lachy>
Woo Hoo! I think I have made my final decision :-)

[10:41:00.0000] <annevk>
getElement and getAllElements?

[10:42:00.0000] <annevk>
match and matchAll?

[10:42:01.0000] <Philip`>
If it's a final decision, you shouldn't actually tell anyone what the decision was, because there's nothing they could do other than argue for changing the decision :-)

[10:42:02.0000] <Lachy>
I know, that's why I didn't say what it is yet

[10:42:03.0000] <Dashiva>
/me sharpens axe

[10:43:00.0000] <Lachy>
you can all wait till I finish writing the rationale and send it to public-webapi

[10:46:00.0000] <hallvors>
/me is patient

[10:46:01.0000] <Lachy>
now the final issue in the spec is to finish reviewing, editing and adding examples.  Then I can get it republised as a WD and then hopefully go LC in a few weeks

[10:46:02.0000] <Dashiva>
How much of the total time has gone to name selection?

[10:47:00.0000] <Lachy>
a few hours per day over the last 3 days

[10:48:00.0000] <Lachy>
a lot of it was spent reading through about 300 emails on the topic

[10:53:00.0000] <Dashiva>
Where is the line between "If we /provide/ version information, we allow others to make use of it" and "we /encourage/ others to make use of it", I wonder

[10:54:00.0000] <Philip`>
Perhaps "If we provide version information, others are more likely to make use of it" - the consequences are important, rather than the direction of the motivation

[12:08:00.0000] <Lachy>
/me is trying to figure out if Sam Ruby is being serious with his proposal for a new HTML MIME type: application/html ???

[12:08:01.0000] <othermaciej>
/me links

[12:09:00.0000] <Lachy>
http://www.w3.org/mid/467BE62A.3060102⊙uic

[13:53:00.0000] <aa>
Hello. I was looking at HTML5 timers, and I was wondering if there is documentation somewhere about which browsers currently support which features.

[13:59:00.0000] <Philip`>
aa: The timers in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-timers.html ?

[14:04:00.0000] <aa>
Philip`: yes, those are the ones

[14:05:00.0000] <aa>
like, for example, do all browsers currently support the extra args in the function pointer overload

[14:05:01.0000] <aa>
(I figure there must have been research on all these at some point)

[14:05:02.0000] <Philip`>
IE7 doesn't

[14:07:00.0000] <Philip`>
FF3 / Opera 9 do, and I expect much older versions of those supported it too, but I don't know if proper test results have been collected anywhere

[14:09:00.0000] <aa>
ok, thanks.

[14:11:00.0000] <Philip`>
(More specifically: I believe proper test results haven't been collected anywhere)

[14:14:00.0000] <hallvors>
oh do we? I actually thought we didn't :-p off to test..

[14:14:01.0000] <hallvors>
javascript:void(setTimeout( function(a){alert(a)}, 100, 'hi'  ));

[14:14:02.0000] <hallvors>
you're right :)

[14:14:03.0000] <aa>
We're going to put timers into Workers in Gears and was just wondering about support for comparison. We'll just do all of them.

[14:16:00.0000] <Philip`>
Firefox is fun because it passes an extra argument to the function, indicating how many milliseconds late it was

[14:16:01.0000] <aa>
yeah "fun". I have been bitten by that bug.

[14:17:00.0000] <othermaciej>
one thing that is weird about timers in browsers is that the rate at which they can fire is limited, due to OS limitations on windows and for compatibility on mac

[14:17:01.0000] <othermaciej>
dunno if the spec handles that

[14:18:00.0000] <othermaciej>
I think IE does not support the extra args in the function case and other browsers don't support the language parameter in the string case

[14:18:01.0000] <Philip`>
I believe browsers vary in terms of whether they run the function multiple times as fast as possible until it catches up with the requested rate, or if they just start dropping calls when they're too slow

[14:19:00.0000] <Philip`>
(Also, Firefox limits the time to be no less than 10msec)

[14:19:01.0000] <aa>
I think we are just going to implement it in terms of nsITimer on Firefox, so it will be whatever it does. Dunno about on windows.

[14:30:00.0000] <Philip`>
From some experiments I tried ages ago: On Windows (where various timer things have 16ms resolution), when doing setInterval(f, 1), everything (Opera, FF, Safari, IE) runs the function once every 16ms

[14:32:00.0000] <Philip`>
When the interval is larger, but the script takes a long time to run, FF remembers how far behind it is and then tries running once every 16ms until it has caught up. None of the other browsers do that - they always just wait another roundup(time, 16ms) before running the function again

[14:33:00.0000] <virtuelv_>
Philip`: You're _sure_ that's accurate?

[14:35:00.0000] <othermaciej>
Philip`: I think in Safari we only throttle to 10ms, not 16ms

[14:35:01.0000] <othermaciej>
Philip`: we don't rely on the Windows system call that would limit it to 16ms resolution IIRC

[14:36:00.0000] <othermaciej>
(could be wrong though)

[14:37:00.0000] <Philip`>
On Linux, Opera runs consistently at 10ms when I do setInterval(f, 1), and FF2 runs slightly less consistently at roughly 10-14ms

[14:37:01.0000] <Philip`>
(Hmm, looks like the interval-catchup has changed in FF3)

[14:38:00.0000] <othermaciej>
on windows the interval varies with the OS and whether you have a single CPU/core or multiple

[14:41:00.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/timer.html - that does setInterval(f, 1), and does lots of computation for the first 64 repeats, then does nothing for the next 192, and reports the measured time intervals via Date()

[14:42:00.0000] <Philip`>
(On Windows, Date() is limited to 16ms resolution, but it should alternate between 16 and 0 if the function is being run more frequently than that)

[14:42:01.0000] <virtuelv_>
note that setInterval with lower than 15/16ms is wildly inaccurate

[14:42:02.0000] <Philip`>
In every browser in Windows (in VMware) I get lots of 16s at the end

[14:43:00.0000] <virtuelv_>
timers don't run more often either, fwiw

[14:44:00.0000] <virtuelv_>
The practical limit for Opera on Linux is 8

[14:44:01.0000] <Philip`>
virtuelv_: Yep, it's just trying to find the maximum frequency which the browser will run at - they all seem to be limited to 16ms on Windows (and less limited on Linux)

[14:45:00.0000] <virtuelv_>
16ms is the safe bet on any platform

[14:46:00.0000] <Philip`>
It's a bit of a pain when you're trying to write real-time games in a web browser :-(

[14:46:01.0000] <virtuelv_>
if you're doing animation, I'd probably just specify something to reach an acceptable target framerate

[14:46:02.0000] <virtuelv_>
20,25 or so

[14:47:00.0000] <Philip`>
...though fortunately my game ended up running at about 8fps, so timers weren't the problem that I had anticipated :-)

[14:47:01.0000] <virtuelv_>
then again, I have some code for a presentation library where I break my own rule, by specifying 0

[14:47:02.0000] <virtuelv_>
for transitions and similar

[14:47:03.0000] <virtuelv_>
hm

[14:48:00.0000] <virtuelv_>
:)

[14:50:00.0000] <Philip`>
https://bugzilla.mozilla.org/show_bug.cgi?id=376643

[14:51:00.0000] <Philip`>
Looks like that's why they stopped the try-to-catch-up-when-running-too-slowly behaviour in FF3

[14:56:00.0000] <Philip`>
http://msdn2.microsoft.com/en-us/library/ms536753.aspx - hmm, did they even try running the second example there?

[15:02:00.0000] <Hixie>
Lachy: of course, ratatouille is the best movie of the year

[15:06:00.0000] <Philip`>
/me wonders if it's possible to get web browsers to load a 0x0 image

[15:06:01.0000] <Philip`>
(I don't think PNG can do that, but I'm not sure about other formats...)

[15:08:00.0000] <Philip`>
(Looks like JPEG probably can't do that either, given how it crashes when I try to save)

[15:21:00.0000] <Philip`>
Hmm, looks like it's not possible at all - I can construct a 0x0 BMP but they refuse to load it

[15:21:01.0000] <Hixie>
rofl @ the e-mail in www-html

[15:24:00.0000] <Hixie>
http://lists.w3.org/Archives/Public/www-html/2007Jun/0008.html

[15:37:00.0000] <othermaciej>
My favorite line: "The Christians took 325 years to produce their spec, before declaring a Rec at the Council of Nicaea."

[15:39:00.0000] <Hixie>
there are definitely some places where i was misquoted

[15:39:01.0000] <Hixie>
for example, not killing people has to be a MUST, not a SHOULD

[15:41:00.0000] <othermaciej>
thou MUST NOT kill

[15:41:01.0000] <Hixie>
ironcially, "thou shalt not kill" is very close to rfc2119 terminology

[15:41:02.0000] <othermaciej>
but what about the exception list?

[15:41:03.0000] <Hixie>
because 2119 defines "shall not"

[15:41:04.0000] <othermaciej>
oh yeah

[15:41:05.0000] <Hixie>
what exceptions?

[15:41:06.0000] <othermaciej>
self-defense?

[15:42:00.0000] <othermaciej>
I think we want to support that, at least as an option

[15:42:01.0000] <Hixie>
you shouldn't kill, even in self-defence

[15:42:02.0000] <Hixie>
valid concern, though

[15:42:03.0000] <Hixie>
i think Bible5 will be easier than SVG5, which the article claims i'll have already done by 2008

[15:43:00.0000] <othermaciej>
with Bible5 you can just delete the mass of non-normative material and not much remains

[15:43:01.0000] <Hixie>
actually that was my first thought when i read it

[15:44:00.0000] <Hixie>
i was like "well that'll be a short book, if i write it"

[15:48:00.0000] <jgraham_>
Have you two considered a career in stand up if this web thing doesn't take off?

[15:49:00.0000] <jgraham_>
The feedline-punchline thing there worked for me anyway

[15:49:01.0000] <jgraham_>
/me goes back to packing

[16:24:00.0000] <Philip`>
Hmm, this run-lots-of-tests-at-once-in-an-iframe system doesn't work too well when half the tests in this section make the browser crash

[16:50:00.0000] <webben>
Hixie: Yesterday you gave an example of a lack of definition in WAI-ARIA about what happens when a element declared as treeitem is a child of an element declared as checkbox, but I'm not quite sure what you meant. What are two of the alternate implementation possibilities you had in mind?

[16:56:00.0000] <Hixie>
i have no idea

[16:57:00.0000] <Hixie>
that's the problem

[16:57:01.0000] <Hixie>
i have no idea what browsers should do


2007-06-23
[17:03:00.0000] <webben>
Hixie: Expose the treeitem as a treeitem role and the checkbox as a checkbox role in the accessibility framework, I think.

[17:03:01.0000] <Hixie>
which means what, assuming you are implementing the accessibility framework?

[17:04:00.0000] <Hixie>
can i activate a treeitem role? what does it do when activated?

[17:04:01.0000] <webben>
Hixie: That's not defined by the role.

[17:04:02.0000] <Hixie>
that's the problem

[17:04:03.0000] <webben>
Hixie: How?

[17:05:00.0000] <webben>
The main point of the roles is to map to roles in accessibility frameworks, not to imply a series of behaviours to be implemented by the browser rather than specified by authors.

[17:05:01.0000] <webben>
(or by specifications like XForms, HTML5, etc.)

[17:06:00.0000] <Hixie>
to me that seems singularily pointless

[17:06:01.0000] <Hixie>
but ok

[17:06:02.0000] <Hixie>
i stil don't know what that means, e.g. from a testing point of view

[17:06:03.0000] <Hixie>
nor do i know what it means to expose an element as having a role to an accessibility framework

[17:07:00.0000] <webben>
Hixie: Have you had a look at the Gecko documentation on exposing HTML content to MSAA?

[17:07:01.0000] <webben>
(and AT-SPI)

[17:07:02.0000] <Hixie>
what about it?

[17:07:03.0000] <Hixie>
i understand that there are system-provided APIs

[17:07:04.0000] <webben>
Hixie: well, that talks about "what it means" (there's an interesting doc also about how to implement an MSAA server)

[17:08:00.0000] <webben>
http://www.mozilla.org/access/windows/msaa-server

[17:08:01.0000] <Hixie>
i just don't know how to tell if an application's implementation is conforming

[17:08:02.0000] <Hixie>
i have JAWS here. work me through a test that shows whether or not a UA implemented a role correctly or not.

[17:08:03.0000] <webben>
Hixie: I think that's verging into the "telling applications and operating systems how to work" rather than the "how to read HTML" category

[17:09:00.0000] <webben>
Hixie: Ah now that sort of test wouldn't be so hard.

[17:09:01.0000] <webben>
If you've got a div made into a WAI-ARIA checkbox, and Firefox fails to expose it as an MSAA checkbox, then that would (likely) be a failure of some sort

[17:09:02.0000] <webben>
Using JAWS to test wouldn't be a great idea though.

[17:09:03.0000] <Hixie>
(also, exposing things to accessibility frameworks isn't enough. if something is a tree item, it should act as a tree item whether or not i have an AT. accessibility isn't just for the disabled.)

[17:10:00.0000] <webben>
Hixie: Yes. But that's not from what I can see the job of WAI-ARIA.

[17:10:01.0000] <Hixie>
how can i tell if firefox exposes it as an MSAA checkbox?

[17:10:02.0000] <webben>
Hixie: use MS's accessibility inspecting tools?

[17:10:03.0000] <Hixie>
the point is that whatever does the job i described above, can automatically do all of the stuff role= can do

[17:10:04.0000] <webben>
or indeed I think the ICITA extension for Firefox now does that

[17:11:00.0000] <Hixie>
so the only way to tell if firefox is doing the right thing is to use a debugging tool? it doesn't actually affect users at all?

[17:11:01.0000] <webben>
Hixie: Not in the case of div widgets.

[17:11:02.0000] <Hixie>
the div widgets *should also act as tree items* even when, e.g., scripting and css are disabled

[17:11:03.0000] <webben>
Hixie: No... the point is that using the debugging tool separates what Firefox is doing from what JAWS is doing with MSAA (and other things)

[17:12:00.0000] <webben>
Hixie: Or fallback.

[17:12:01.0000] <webben>
Hixie: Which is what you suggesting for HTML5 in current UAs like IE.

[17:12:02.0000] <webben>
*suggested

[17:12:03.0000] <Hixie>
?

[17:13:00.0000] <webben>
Yesterday you said new HTML5 widgets could be scripted and styled to look the same in IE as in other browsers. 

[17:13:01.0000] <Hixie>
sure, fallback support in many cases has to be secret

[17:13:02.0000] <webben>
sorry?

[17:13:03.0000] <Hixie>
we're talking about browsers that implement the new features (be that wairole or whatever)

[17:13:04.0000] <Hixie>
er

[17:13:05.0000] <Hixie>
has to be scripted!

[17:13:06.0000] <Hixie>
my bad

[17:14:00.0000] <webben>
Hixie: Yes, but if the scripting is changing the DOM so that checkboxes become divs... then the semantics need to be preserved.

[17:15:00.0000] <Hixie>
if the scripting is changing the DOM so that checkboxes become divs, the scripting has removed the semantics.

[17:15:01.0000] <webben>
(and that's what authors will continue to do in the short to medium term if indeed they bother with fallbacks at all, given lack of implementations for XBL2)

[17:15:02.0000] <webben>
Hixie: Not with WAI-ARIA.

[17:15:03.0000] <Hixie>
if this is about "preserving semantics" they should be preserved for *all* users, not just those that use ATs

[17:16:00.0000] <webben>
Hixie: What does "preserving semantics" /mean/ for non-AT users of Dojo?

[17:16:01.0000] <webben>
Hixie: e.g. is this about restyling?

[17:16:02.0000] <Hixie>
it means that if they have, e.g., a bookmarklet that checks all checkboxes, that should still work

[17:17:00.0000] <webben>
Hixie: I guess WAI-ARIA faciliates that through XML Events.

[17:17:01.0000] <Hixie>
eh?

[17:18:00.0000] <Hixie>
how does XML Events help anything in IE

[17:18:01.0000] <Hixie>
heck how does WAIROLE help anything in IE

[17:19:00.0000] <webben>
Hixie: It doesn't. It helps the users who can't use Ajax apps in IE by giving them the option of using Fx instead.

[17:20:00.0000] <webben>
(Fx being the other major window browser that has screen reader support)

[17:20:01.0000] <webben>
*Windows

[17:20:02.0000] <Hixie>
so why not have firefox implement xbl2 instead?

[17:20:03.0000] <Hixie>
since you're requiring the authors to do something in their markup anyway, and since you're requiring users to switch to another UA anyway, why not just do it right?

[17:21:00.0000] <Hixie>
wairole seems to be so fundamentally the wrong way to address the problem that I just don't understand how it came to be

[17:21:01.0000] <webben>
Hixie: That's something for the XBL2 spec writers to take up with AT developers, browser developers, and framework developers, none (?) of whom seem to have shown a vast interest in XBL2.

[17:23:00.0000] <webben>
Hixie: I suspect, for one thing, it's a lot easier to add WAIROLES to existing codebases using Dojo than to convert Dojo apps to XBL2.

[17:23:01.0000] <Hixie>
sure, but why isn't it up to the people who designed wairole to design a decent solution?

[17:23:02.0000] <webben>
but that's only a guess

[17:23:03.0000] <webben>
Hixie: They're not solving the same problem.

[17:24:00.0000] <Hixie>
the problem is "people are using html to convey semantics without encoding those semantics in the language", right?

[17:24:01.0000] <webben>
(Also there's no incentive to use XBL2, because then you couldn't control presentation in IE.)

[17:24:02.0000] <webben>
Hixie: Not entirely no.

[17:24:03.0000] <Hixie>
i don't really understand the problem then

[17:24:04.0000] <webben>
Hixie: But that's certainly a big part of it.

[17:25:00.0000] <othermaciej>
I think the problem being solved is "people want to make existing web applications that contain custom controls work with existing accessibility tools without first implementing a major feature in all browsers and then rearchitecting their web apps to use a different approach to custom controls"

[17:25:01.0000] <webben>
Hixie: the XML events stuff (independence of input devices) is another big part of it; nothing to do with misuse of HTML semantics

[17:26:00.0000] <webben>
othermaciej: That's certainly how WAI-Roles are being used by Dojo, yes.

[17:26:01.0000] <Hixie>
webben: what's the problem being solved by XML Events?

[17:26:02.0000] <othermaciej>
I have no idea what XML Events has to do with it though

[17:26:03.0000] <webben>
Hixie: accesskey for one thing

[17:26:04.0000] <othermaciej>
that's just a syntax for attaching event handlers, right?

[17:27:00.0000] <webben>
othermaciej: the ARIA roadmap tries to explain what these things have to do with one another

[17:27:01.0000] <Hixie>
(note that i have nothing against stop-gap technologies, i'm only objecting to including wai-role and related stuff in html5 as a long-term solution)

[17:27:02.0000] <webben>
othermaciej: it's a declarative syntax

[17:27:03.0000] <webben>
http://www.w3.org/TR/aria-roadmap/#xmlevents

[17:27:04.0000] <Hixie>
webben: can you describe the problem being solved by xml events in a complete, self-contained sentence?

[17:28:00.0000] <webben>
Hixie: It seems to me they're trying to solve more than one problem.

[17:28:01.0000] <othermaciej>
"Having the ability to use XML to integrate listeners and handlers will allow us in in future versions of the XML event specification to tie a descriptive purpose to the handlers."

[17:28:02.0000] <othermaciej>
this is handwaving nonsense

[17:29:00.0000] <Hixie>
indeed

[17:29:01.0000] <webben>
Hixie: e.g. different systems and websites competing for keybindings.

[17:29:02.0000] <webben>
and e.g. not knowing what functionality a widget has

[17:29:03.0000] <othermaciej>
the idea of writing a description for an individual event handler for presentation to the user is completely ill-conceived

[17:29:04.0000] <webben>
what "onclick" actually doers

[17:29:05.0000] <webben>
*does

[17:29:06.0000] <othermaciej>
XML Events doesn't solve that problem, and it's not the right problem to solve

[17:29:07.0000] <othermaciej>
you want to describe the purpose of the button

[17:30:00.0000] <othermaciej>
not the event handlers the fire when you click it

[17:30:01.0000] <webben>
othermaciej: with a button, it's trivial

[17:30:02.0000] <webben>
what about (e.g.) Flickr mouseovers

[17:30:03.0000] <Hixie>
i still haven't actually heard a description of the problem (other than the one othermaciej quoted, which as he says, is nonsense)

[17:30:04.0000] <webben>
controls on the web can get very complicated

[17:31:00.0000] <Hixie>
adding more technology is not a solution to the problem of "controls on the web can get very complicated"

[17:31:01.0000] <othermaciej>
sure, but you don't want to describe every bit of that complexity

[17:31:02.0000] <othermaciej>
I'm not sure what use flickr mouseovers would be to a blind user anyway, but it seems like just reading the text that would appear when the user activates the relevant element is more useful than saying that mousing in makes some text appear

[17:32:00.0000] <webben>
othermaciej: If you look at the example list the roadmap provides, it's quite traditional, e.g. "Submit the form"

[17:32:01.0000] <webben>
othermaciej: I'm not really sure what you mean there.

[17:32:02.0000] <othermaciej>
webben: wouldn't the label of the button already describe what it does?

[17:32:03.0000] <othermaciej>
webben: after all, that's the only info sighted users get

[17:33:00.0000] <othermaciej>
(barring image buttons, which presumably have alt text for accessibility)

[17:33:01.0000] <othermaciej>
you want to describe the button to all users

[17:33:02.0000] <othermaciej>
describing its onclick handlers is pointless

[17:33:03.0000] <othermaciej>
particularly for things where multiple onclick handlers will apply, it's likely that describing each individually will be far more confusing than just describing the control as a whole

[17:34:00.0000] <othermaciej>
so both the proposed use for XML Events and the idea that XML Events uniquely addresses that need are wrong

[17:35:00.0000] <webben>
othermaciej: Like I said, trying to infer anything from the simplest possible case (a button!) doesn't really help.

[17:40:00.0000] <webben>
I suppose another interesting example would be scrolling and zooming in Google Maps

[17:41:00.0000] <webben>
othermaciej: re Flickr mouseovers, I do think they would be useful to a blind user and in any case there are plenty of other groups who require device independence (e.g. switch access users) but could /see/ the annotations.

[17:43:00.0000] <webben>
in complex interfaces, the function of something is not that clear from its label

[17:43:01.0000] <webben>
e.g. the Firefox bookmarks menu on Linux and Windows (but not Mac)

[17:43:02.0000] <webben>
right click on a bookmark and you get a context menu where you can edit the bookmark

[17:44:00.0000] <webben>
left click and you go to the bookmark

[17:44:01.0000] <webben>
ctrl + left click and you go to the bookmark in a new tab

[17:51:00.0000] <webben>
othermaciej: re "describing each individually", my impression from the roadmap document is that you would associate multiple triggers with a single "Event" that would be described

[17:51:01.0000] <webben>
not that all triggers would have to be enumerated to users

[17:52:00.0000] <webben>
"uniformly integrate event listeners and associated event handlers"

[17:53:00.0000] <webben>
this gets a bit clearer in the XForms section that follows

[17:56:00.0000] <othermaciej>
webben: I'd say any action that can only be done through right click is an accessibility problem

[17:56:01.0000] <othermaciej>
(and, frankly, a usability problem)

[17:57:00.0000] <webben>
othermaciej: Sure. I'm not sure what you think that implies for what we've been saying though.

[17:57:01.0000] <othermaciej>
google maps, other than the panning of the map itself, is just a bunch of buttons and a slider

[17:57:02.0000] <othermaciej>
which could have alt text

[17:58:00.0000] <webben>
and zooming, and any other custom functionality added by individual developers

[17:58:01.0000] <webben>
oh and triggering popup markers

[17:58:02.0000] <webben>
and so on and on

[17:58:03.0000] <othermaciej>
zooming is the slider I was referring to

[17:58:04.0000] <othermaciej>
everything else besides the drag-panning just takes an action when clicked

[17:58:05.0000] <webben>
othermaciej: you can "pan" with the buttons too

[17:58:06.0000] <othermaciej>
and so is logically a button

[17:59:00.0000] <webben>
so i'm not sure what you meant by "other than"

[17:59:01.0000] <othermaciej>
of course, nothing in google maps uses the semantically correct elements even when they could

[17:59:02.0000] <webben>
well no ... which is rather grist to the mill of Firefox's approach

[17:59:03.0000] <othermaciej>
yes, you can pan with buttons too

[18:00:00.0000] <webben>
developers will continue to use divs and spans that they can hack to look good in IE

[18:00:01.0000] <othermaciej>
why would it be better to advise them to use role="button" on their img elements instead of using a proper button control?

[18:00:02.0000] <othermaciej>
that can be made to look just as good to IE

[18:00:03.0000] <webben>
othermaciej: Nobody /does/ advise that.

[18:00:04.0000] <webben>
(AFAIK)

[18:01:00.0000] <webben>
it's not (just) about the very best practice, but about accommodating the "real" world.

[18:01:01.0000] <othermaciej>
sure, but in this case, doing the right thing is in no way harder to do or less compatible than using role

[18:02:00.0000] <webben>
othermaciej: Good luck convincing Dojo of that.

[18:02:01.0000] <othermaciej>
Dojo didn't make Google Maps, Google did

[18:02:02.0000] <webben>
(and Google Maps ... and most of the other div/span Ajax contraptions)

[18:03:00.0000] <othermaciej>
so far as google maps goes, though, the hard part is making the map data itself useful to a blind user

[18:03:01.0000] <othermaciej>
not the controls

[18:03:02.0000] <webben>
othermaciej: Not that hard. We already have one solution for that. (See Raman's work with GMaps in Emacspeak.)

[18:04:00.0000] <webben>
(it depends on what we mean by map data, I suppose)

[18:04:01.0000] <webben>
e.g. directions are very simple

[18:04:02.0000] <webben>
but sorry, I'm drifting off-topic there

[18:04:03.0000] <othermaciej>
right, I meant the map content with the street layout and labels

[18:05:00.0000] <othermaciej>
zooming and panning that is pretty unimportant if you can't see the map

[18:05:01.0000] <webben>
othermaciej: unless you need someone else to see the map

[18:05:02.0000] <webben>
stuff on the web quickly becomes a social object

[18:06:00.0000] <webben>
maps and photos become sites of social interaction and sharing and commentary

[18:06:01.0000] <webben>
(one of the reasons a blind person might be interested in flickr annotations :) )

[18:07:00.0000] <webben>
othermaciej: but again XML events is about more than just blind people

[18:07:01.0000] <othermaciej>
XML events doesn't actually *do* anything though

[18:08:00.0000] <othermaciej>
it's just XML syntactic sugar for the DOM Events API

[18:08:01.0000] <othermaciej>
if it might have some feature added in the future then great, but that could just as well be added to the DOM

[18:08:02.0000] <webben>
(incidentally, there seems to be a misconception in the HTML WG that screen reader users don't use mice at all, but actually mouse control (or failing that mouse keys) is an important mode of interaction with desktop apps)

[18:09:00.0000] <webben>
othermaciej: I'm not sure there's an ultimate difference between adding things to markup and adding things to the DOM is there?

[18:09:01.0000] <webben>
othermaciej: surely the key point is not to force UAs to try and guess what scripts do...

[18:10:00.0000] <othermaciej>
sure, but XML Events has nothing to do with that

[18:10:01.0000] <webben>
othermaciej: it does when you have event traps for particular key presses (for example)

[18:10:02.0000] <othermaciej>
but again, a UA should not need to

[18:10:03.0000] <webben>
the ua can't run the script to work out what pressing F does

[18:10:04.0000] <othermaciej>
the UA can be made clear to sighted users without annotating scripts for purpose

[18:11:00.0000] <othermaciej>
er

[18:11:01.0000] <webben>
do you mean the webapp interface can be made... ?

[18:11:02.0000] <othermaciej>
s/the UA/a web app/

[18:11:03.0000] <webben>
othermaciej: I don't think that's as simple as you imply.

[18:11:04.0000] <othermaciej>
so if it contains enough info for that, then the key is to encode that info in a way that AT can use

[18:12:00.0000] <webben>
if you look at a desktop app, it doesn't expose all its functionality and event handling to view

[18:12:01.0000] <othermaciej>
why does a blind user need to know what right clicking on a random element will do more than I do?

[18:12:02.0000] <webben>
this is increasingly true of web apps too

[18:13:00.0000] <webben>
othermaciej: Out of context, that's an impossible question to answer. It depends what right clicking does...

[18:13:01.0000] <othermaciej>
well, I don't know without trying it

[18:13:02.0000] <othermaciej>
I assume that by convention it would display a context menu unless some sort of instruction told me otherwise

[18:13:03.0000] <webben>
othermaciej: how do you try it if you can't right-click?

[18:14:00.0000] <othermaciej>
webben: presumably AT would have a feature to context-click a chosen element

[18:14:01.0000] <webben>
othermaciej: Indeed it might. But that's not necessarily the same as right-clicking in a webapp.

[18:15:00.0000] <webben>
e.g. i can press shift + f10 in Fx to open a context menu

[18:15:01.0000] <othermaciej>
(one difficulty there is that generally everything would have a context menu so you can't limit it to only some items)

[18:15:02.0000] <webben>
but that wouldn't get caught by a script checking for right mouse clicks

[18:15:03.0000] <webben>
so my impression is that XML events would be used to separate commands (what you can actually do) from triggers (what you can do to accomplish commands)

[18:16:00.0000] <othermaciej>
XML events doesn't actually do that though

[18:16:01.0000] <othermaciej>
(although there is a <command> element in HTML5 that does)

[18:16:02.0000] <Lachy>
wow, Bible5 is a great idea! :-) I think it'll be a great opportunity to deal with the lack of interoperability between scientists and creation scientists.

[18:17:00.0000] <othermaciej>
won't we also need Scientific Method 5?

[18:17:01.0000] <othermaciej>
or would Bible5 support both rational and faith-based serializations?

[18:18:00.0000] <webben>
lol

[18:19:00.0000] <Hixie>
faith-based interaction will be non-conforming, though supported for back-compat

[18:21:00.0000] <Lachy>
I don't think so.  The faith based serialisation would claim the existence of the almighty Hickson without any empirical evidence to support their claim.  The rational based serialisation would claim that since the only evidence we have for his existence is hearsay, and so we must remain agnostic to his existence.

[18:23:00.0000] <Hixie>
good lord, let's not try to posit my omniscience

[18:24:00.0000] <Lachy>
the problem is that simply claiming that bible5 is the infallible word of Hixie doesn't constitute evidence.

[02:16:00.0000] <Hixie>
/me is deep in the encoding stuff getting his hands very dirty

[02:55:00.0000] <Hixie>
hah, Lachy is trying to get me in trouble :-P

[05:28:00.0000] <annevk>
got to love bible5

[05:38:00.0000] <annevk>
whoa, IE people on the public-html list!

[05:38:01.0000] <annevk>
hurray

[05:39:00.0000] <Lachy>
has Chris been the only MS guy on the list until now?

[05:40:00.0000] <annevk>
think so

[05:40:01.0000] <annevk>
but this question is related to implementations, nice step forward from previous discussions

[05:43:00.0000] <annevk>
selectAllElements is long

[05:44:00.0000] <annevk>
but I suppose it's sort of acceptable

[05:44:01.0000] <annevk>
selectElement is too, but not as long and cumbersome to type as getElementById

[05:44:02.0000] <Lachy>
I know, but it doesn't have too many uppercase letters in it, so it's not too hard to type

[05:48:00.0000] <annevk>
hmm UTF-32 is dropped

[05:49:00.0000] <annevk>
don't think we'll drop it though

[05:50:00.0000] <Lachy>
hmm. is UTF-32 freqently misimplemented any more than UTF-8 and UTF-16?

[05:55:00.0000] <Lachy>
would anyone like to help write some examples for selectors api?  I need to revise the one marked as an issue in the spec and I should provide a demonstration of using the default namespace

[05:55:01.0000] <Lachy>
any idea of a use case where it is useful to specify a default namespace?

[05:56:00.0000] <annevk>
pointer?

[05:56:01.0000] <Lachy>
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8

[05:57:00.0000] <annevk>
It's interesting how it went from WHATWG's HTML5 to W3C's HTML5 http://blog.codedread.com/archives/2007/06/22/mollys-grenade/

[05:58:00.0000] <annevk>
http://ccapeng.blogspot.com/2007/06/html-required-fields.html is weird

[05:58:01.0000] <annevk>
Maybe we shoul review WCAG?

[05:59:00.0000] <annevk>
hmm, people are also referring to the html4-differences doc as the draft spec for html5...

[05:59:01.0000] <Lachy>
lol

[05:59:02.0000] <webben>
Well, screen readers will support the later and not the former.

[06:00:00.0000] <annevk>
seems pretty pointless

[06:00:01.0000] <webben>
but will hopefully support both in future

[06:00:02.0000] <annevk>
especially since setAttributeNS is not supported by IE

[06:00:03.0000] <webben>
annevk: it doesn't matter since the target screen readers can use Fx.

[06:01:00.0000] <webben>
basically the only advantage of continuing to use IE is that Adobe can't be bothered to support Fx properly

[06:01:01.0000] <webben>
(for Flash content)

[06:01:02.0000] <annevk>
would be nice if these screen reader people got involved in html5

[06:02:00.0000] <webben>
(well, or if you use Dolphin or BAUM or Thunder screen readers)

[06:02:01.0000] <annevk>
might save them some trouble in the future

[06:02:02.0000] <webben>
since those are still IE-dependent

[06:02:03.0000] <webben>
annevk: Yes. I've been saying that for some time.

[06:03:00.0000] <webben>
annevk: I think they're actually terribly busy though.

[06:03:01.0000] <webben>
they tend to have very few staff and to be busy to dealing with a lot of non-web related stuff

[06:03:02.0000] <webben>
e.g. Vista

[06:03:03.0000] <annevk>
did you tell them?

[06:03:04.0000] <webben>
or e.g. basic functionality in the case of FOSS screen readers

[06:03:05.0000] <annevk>
Lachy, hmm... not really

[06:03:06.0000] <webben>
annevk: i did a post to the mozilla accessibility-dev list a few weeks ago

[06:04:00.0000] <annevk>
Lachy, namespaces are in there for correctness, not because they have much use cases on the web...

[06:04:01.0000] <webben>
annevk: I've been thinking about doing something similar with GW-Micro

[06:04:02.0000] <annevk>
webben, cool

[06:04:03.0000] <annevk>
go for it! :)

[06:04:04.0000] <Lachy>
annevk: I realise that, that's why I can't think of any

[06:04:05.0000] <webben>
unfortunately there's no "official" Freedom Scientific list

[06:06:00.0000] <webben>
at the very least, they would be able to correct misconceptions like the idea that screen reader users don't use mice

[06:07:00.0000] <annevk>
hmm, we need to finish this C impl of the HTML5 parser if we want to make this web survey thing happen with "reproducable" results

[06:07:01.0000] <webben>
I did manage to persuade GW-Micro to put their release history (basically the readme file for each version) online, which should help.

[06:07:02.0000] <webben>
annevk: web survey thing?

[06:07:03.0000] <Lachy>
oh, perhaps I could add an XBL fragment to the head of an XHTML document, and then use selectElement("div", res); with the default NS as XHTML, so that I don't select <div> from the XBL NS instead.

[06:08:00.0000] <annevk>
finding out what is being used out there without relying on Google to provide sanitised numbers

[06:08:01.0000] <annevk>
Lachy, XBL is a nice example

[06:09:00.0000] <annevk>
Lachy, you need to fix up the conformance criteria btw

[06:09:01.0000] <webben>
annevk: Cool. Glad to hear there's a project to do that. But we really need qualitative studies too.

[06:09:02.0000] <Lachy>
annevk: what's the specific issue?

[06:09:03.0000] <annevk>
webben, what project?

[06:09:04.0000] <annevk>
Lachy, "conforming documents"

[06:09:05.0000] <webben>
annevk: provide numbers.

[06:09:06.0000] <annevk>
and authoring tools...

[06:10:00.0000] <annevk>
webben, well, so far there's only the project Hixie does

[06:10:01.0000] <annevk>
I'd like to have a second, open one

[06:10:02.0000] <webben>
annevk: Yeah, that would be neat.

[06:11:00.0000] <Lachy>
do you mean that "One that produces conforming documents." isn't a good defintion of a conforming authoring tool?

[06:11:01.0000] <webben>
What I've been wondering is whether one could use the WayBack archive somehow.

[06:11:02.0000] <webben>
as a readily available cache

[06:11:03.0000] <annevk>
Lachy, I'm not sure they make much sense

[06:11:04.0000] <webben>
i dunno

[06:11:05.0000] <Lachy>
ok, I'll think about it

[06:11:06.0000] <annevk>
better to scrape live sites

[06:12:00.0000] <webben>
I wonder how one would deal with the issues around public cacheing that webcitation and WayBack have to deal with

[06:12:01.0000] <webben>
(re removing stuff from the cache when domain owners request it for example)

[06:14:00.0000] <Lachy>
perhaps I should rename "conforming document" to a "conforming script" instead, and then define conforming authoring tool as a tool that produces conforming scripts.

[06:14:01.0000] <Lachy>
or s/script/application/

[06:14:02.0000] <Lachy>
/me doesn't know

[06:14:03.0000] <annevk>
webben, it's not about caching, it's just about running algorithms on those documents and publishing the results; I don't think we'd cache them, but it's far from finished anyway

[06:14:04.0000] <annevk>
our current tools are good enough to survey about 2500 sites...

[06:15:00.0000] <annevk>
in a reasonable time

[06:15:01.0000] <webben>
annevk: Well you'd want to be able to cache them in order to qualify the results.

[06:15:02.0000] <annevk>
Lachy, that might work, or just have conforming user agents

[06:15:03.0000] <annevk>
webben, I don't understand

[06:15:04.0000] <webben>
e.g. so we've got a load of table elements or summary attributes, but then what are these actually being used for?

[06:16:00.0000] <annevk>
oh, you could store the URLs I suppose

[06:16:01.0000] <webben>
annevk: But that's not reproducible.

[06:16:02.0000] <annevk>
that's not really a concern right now anyway

[06:16:03.0000] <webben>
Well, I guess it is reproducible to some extent actually.

[06:17:00.0000] <webben>
but it's a changing phenomenon

[06:17:01.0000] <Lachy>
hmm.  I see XHR only has conforming UA as well

[06:17:02.0000] <webben>
Lachy: I can't see any other way then to talk about producing conforming documents/apps for a document/app spec.

[06:18:00.0000] <annevk>
annoying, http://xhtml.se/ gives a parse error

[06:18:01.0000] <webben>
Lachy: Authoring tools might have to conform to other things (e.g. ATAG) in order to produce conforming docs in the first place though

[06:18:02.0000] <annevk>
(fortunately Opera has "reparse as HTML" ...)

[06:19:00.0000] <webben>
annevk: yeah it's a good feature :)

[06:19:01.0000] <webben>
be nice if browsers had that for other things

[06:19:02.0000] <annevk>
unescaped &

[06:19:03.0000] <webben>
e.g. open a word document and get the option to parse it into HTML

[06:19:04.0000] <annevk>
it would be nice if XML had sane error handling

[06:19:05.0000] <webben>
or PDF

[06:20:00.0000] <annevk>
that would be  a different feature

[06:20:01.0000] <webben>
It's true it wouldn't be error handling. :)

[06:20:02.0000] <annevk>
"parse as HTML" is just feeding the exact same byte stream in an HTML parser

[06:21:00.0000] <annevk>
nothing to do with conversion

[06:21:01.0000] <webben>
annevk: I'd say that is conversion of sorts.

[06:21:02.0000] <annevk>
whatever

[06:35:00.0000] <annevk>
application/html?!

[06:35:01.0000] <annevk>
hah

[06:36:00.0000] <Lachy>
annevk: do you think sam ruby was being serious with that suggestion?  I couldn't tell

[06:36:01.0000] <annevk>
he proposed application/xhtml at some point on his blog

[06:36:02.0000] <annevk>
I'm not sure why he thinks deploying a new MIME type would work and why we want to do it in the first place though

[06:37:00.0000] <annevk>
it violates all kinds of design principles

[06:37:01.0000] <Lachy>
doesn't he understand that they already tried the approach of changing MIME type with application/xhtml+xml, and that has so far failed

[06:37:02.0000] <annevk>
dunno

[06:37:03.0000] <annevk>
I guess I'll just ignore it for now

[06:37:04.0000] <annevk>
Don't want to get involved in the versioning debate

[06:38:00.0000] <annevk>
you got an interesting response to your longdesc thingie as well

[06:38:01.0000] <annevk>
lol

[06:38:02.0000] <Lachy>
the one from steve faulkner?

[06:39:00.0000] <annevk>
the one that said "who cares if it's useless"

[06:39:01.0000] <Lachy>
yeah, I didn't get that, since that is a self defeating argument.  That's why I assumed he meant who care's if it's used, which makes more sense in the context

[06:44:00.0000] <annevk>
It seems that the accessibility people get upset because the draft doesn't change on a whim

[06:45:00.0000] <annevk>
"And why should we bother? There has been a lot of efforts made previously by John (Folliot) and others in order to save summary and headers in tables. Still, the draft hasn't backed out one bit on the subject."

[06:45:01.0000] <Lachy>
they get upset when someone disagrees with them, or tries to achive the same result using a different method

[06:45:02.0000] <Lachy>
see my response to that, I think I explained the situation well enough

[06:47:00.0000] <annevk>
yeah, seems like it

[06:47:01.0000] <annevk>
we tried that before though

[06:47:02.0000] <annevk>
it's quite hard to get through

[06:48:00.0000] <webben>
Lachy: actually looks to me reading that like he meant "who cares if it's used"

[06:48:01.0000] <webben>
but i dunno

[06:48:02.0000] <webben>
the notion that screen readers are only just implementing longdesc is wrong

[06:49:00.0000] <webben>
window-eyes has supported it since at least 4.5; JAWS since around 4.01

[06:49:01.0000] <Lachy>
what about HPR?

[06:49:02.0000] <webben>
Lachy:  that's abandonware

[06:49:03.0000] <webben>
but I'll try and find out

[06:49:04.0000] <Lachy>
oh, I didn't know

[06:50:00.0000] <webben>
Lachy: I'm trying to find out whether there's anyway to get HAL to support it (HAL isn't abandonware)

[06:50:01.0000] <Lachy>
I don't use screen readers, cause they're so damn difficult to use and they don't provde a good web developer versions

[06:50:02.0000] <webben>
Lachy: what would a good webdev version be?

[06:51:00.0000] <webben>
(and how can it get better than free or bundled versions e.g. Orca, NVDA, VoiceOver)

[06:51:01.0000] <Lachy>
one that's free and features tools that a useful for web developers to test pages

[06:51:02.0000] <webben>
Lachy: I'd go with the ICITA firefox accessibility extension (simply awesome) + Window-Eyes demo

[06:51:03.0000] <webben>
(30 minutes per Windows session)

[06:51:04.0000] <annevk>
you shouldn't have to test AT software

[06:51:05.0000] <Lachy>
does that mean I need to restart every 30 minutes to keep using it?

[06:52:00.0000] <webben>
Lachy: yes ... 30 minutes is quite a long time in practice; and restarting is fast if you're using Win in a VM

[06:52:01.0000] <webben>
(and really, there's no other way to use Win ;) )

[06:52:02.0000] <webben>
the bore is JAWS, which is available in a demo version whose EULA forbids webdevs from using it for testing

[06:52:03.0000] <Lachy>
no, that's unacceptable.  I tried it with the JAWS 40 min trial before, and it was so annoying

[06:53:00.0000] <webben>
/me shrugs. I test like that all the time.

[06:53:01.0000] <webben>
but like I say, there are lot of free options

[06:53:02.0000] <Lachy>
the other problem is usability.  I want a screen reader built for people who can see, that is designed for testing with

[06:54:00.0000] <webben>
Lachy: I think that would largely defeat the point.

[06:54:01.0000] <webben>
It's key to understand how screen reader users use webpages.

[06:54:02.0000] <webben>
Not just have a tech that reads the page to you.

[06:55:00.0000] <Lachy>
no, not if it simulated it without hijacking my keyboard shortcuts

[06:55:01.0000] <webben>
in any case, Window-Eyes has plenty of visual interface

[06:55:02.0000] <webben>
e.g. the list of links

[06:55:03.0000] <webben>
Lachy: Well that's useful too. Alerts people to the fact that Ajax shortcuts may conflict with AT.

[06:55:04.0000] <webben>
ditto VoiceOver also has a visual list of items and links

[06:56:00.0000] <Lachy>
Ajax shortcuts are annoying anyway, especially if they interfere with find-as-you-type

[06:56:01.0000] <webben>
Indeed, and that wouldn't be as obvious if you had a Firefox simulation that behaved just like IE ;)

[06:57:00.0000] <webben>
remove the interface from the screen reader, and it becomes much less valuable as a testing tool; might as well just comply with the guidelines

[06:57:01.0000] <webben>
but in any case there are plenty of testing tools that don't interfere with shortcuts

[06:57:02.0000] <webben>
including the ICITA extension I mentioned and Fangs

[06:58:00.0000] <Lachy>
it doesn't have to remove it completely, just provide a way for me to enable it when I need it and easiily disable it when I don't.

[06:58:01.0000] <webben>
Lachy: how about turning the reader off and turning it on again?

[06:58:02.0000] <Lachy>
takes too long

[06:58:03.0000] <webben>
(again, I do that all the time with VO, there's even a keyboard shortcut for it)

[06:59:00.0000] <Lachy>
enabling/disabling the UI should be instantaneous

[06:59:01.0000] <webben>
Lachy: well, it takes time, there's no way around having to load the speech capabilities.

[06:59:02.0000] <webben>
the only case where I think that's a valid criticism is Fire Vox, where there's no quick way to turn it of and on.

[06:59:03.0000] <webben>
afaik

[07:01:00.0000] <Lachy>
well, my experience with JAWS was terrible.  The UI was so difficult to understand and figure out.  After several hours searching through documentation, I still never found, for example, how to get it to read a title attribute

[07:01:01.0000] <webben>
Lachy: A

[07:02:00.0000] <webben>
ah yes, you want the shortcut key for extended element information

[07:02:01.0000] <Lachy>
but even tasks that should be simple, like controlling where it should read and stop reading.

[07:03:00.0000] <webben>
did you look at the list of keyboard shortcuts?

[07:03:01.0000] <Lachy>
nah, I won't use it anyway as long as they keep the stupid time limits

[07:03:02.0000] <webben>
Lachy: insert + shift +f1  and ctrl+ ins + shift + F1 for extended element info

[07:04:00.0000] <Lachy>
yikes!

[07:04:01.0000] <webben>
ctrl to interrupt speech is probably what you want

[07:04:02.0000] <webben>
Lachy: if you think you've got keyboard shortcut problems ... ;)

[07:05:00.0000] <webben>
Lachy: the Windows-Eyes demo you can mouse around a lot though

[07:05:01.0000] <Lachy>
ok, whatever

[07:06:00.0000] <webben>
I agree the documentation could be improved. OTOH the documentation for browsers is horrific too.

[07:06:01.0000] <Lachy>
at least browsers are somewhat intuitive

[07:06:02.0000] <webben>
(actually in fairness Opera isn't too bad from what I've seen)

[07:06:03.0000] <webben>
Lachy: Not really.

[07:06:04.0000] <Lachy>
what's not intuitive?

[07:06:05.0000] <webben>
they're heavily reliant on people being familiar with WIMP interfaces

[07:06:06.0000] <webben>
screen readers are heavily reliant on other forms of familiarity

[07:06:07.0000] <Lachy>
WIMP?

[07:07:00.0000] <webben>
windows-icon-mouse-pointer

[07:07:01.0000] <webben>
*familiarity with other things, rather

[07:07:02.0000] <annevk>
ah, authors should not use UTF-32

[07:07:03.0000] <Lachy>
well, that's sort of my point from earlier.  Design a screen reader for WIMP interfaces, aimed at web devs who can see, and it would really help

[07:08:00.0000] <webben>
Lachy: I can't see how that would work.

[07:08:01.0000] <webben>
lots of new navigation options in a menu?

[07:08:02.0000] <annevk>
would be fun if someone from us made a comparison of XHTML2 and XHTML5 too

[07:09:00.0000] <Lachy>
instead of requiring keyboard shortcuts to control everything, provde clearly labelled aon screen menus, buttons, etc. that simulate the keyboard shortcuts

[07:09:01.0000] <Aidan_>
Hi

[07:09:02.0000] <Lachy>
s/aon/on/

[07:09:03.0000] <webben>
Lachy: well i suppose you could build an Fx extension to do that

[07:09:04.0000] <webben>
Lachy: you might suggest it to the ICITA folks

[07:10:00.0000] <Lachy>
I'll have to look at what they provide first

[07:10:01.0000] <webben>
although I guess that doesn't handle the reading out loud aspect

[07:10:02.0000] <webben>
Oh I'd definitely take a look if you haven't already.

[07:10:03.0000] <Lachy>
what do you mean? why wouldn't it?

[07:10:04.0000] <webben>
Lachy: ICITA doesn't read the text.

[07:10:05.0000] <Lachy>
then what does it do?

[07:10:06.0000] <webben>
it provides navigational and testing tools

[07:10:07.0000] <annevk>
hi Aidan_

[07:10:08.0000] <webben>
it's easier to see than explain

[07:11:00.0000] <Philip`>
In terms of doing surveys of 2500 sites in "a reasonable time", that's partly limited by me considering half an hour to be 'a reasonable time' and not wanting to bother waiting much longer ;-)

[07:12:00.0000] <Aidan_>
I want join to whatwg where i can do that?

[07:12:01.0000] <annevk>
half an hour is reasonable

[07:12:02.0000] <Lachy>
why does it take that long?

[07:12:03.0000] <annevk>
Aidan_pl, http://www.whatwg.org/mailing-list#specs

[07:12:04.0000] <Lachy>
is it because you're computer is slow, or because python can't process the pages too quickly?

[07:13:00.0000] <Philip`>
Also I need to update my tools to stop using SQLite to download pages into, because it keeps aborting with locked-database exceptions and I have to keep manually fixing it...

[07:13:01.0000] <annevk>
Aidan_pl, you can also contribute on the forums (forums.whatwg.org) or by writing blogposts etc.

[07:13:02.0000] <annevk>
Philip`, that sounds annoying

[07:14:00.0000] <Philip`>
I can't actually remember how long it took - might have been quite a bit less than half an hour

[07:14:01.0000] <annevk>
Philip`, maybe we could set up some kind of distributed computing with all members of the mailing list and have everyone run the script :)

[07:14:02.0000] <webben>
I was about to suggest that.

[07:14:03.0000] <webben>
if the only factor is bandwidth/time

[07:14:04.0000] <Philip`>
but mostly it just takes a while to download all the pages (even doing lots in parallel), and then takes a longer while to parse them all (which can't be done in parallel when I only have one processor)

[07:15:00.0000] <Philip`>
I have plenty of bandwidth here, so that part isn't a problem :-)

[07:15:01.0000] <Lachy>
annevk: I've an idea for a while to write a FF extension that does surveys on pages as the user surfs the web, and then submits it all to a central server later

[07:15:02.0000] <Philip`>
The other main problem is getting a list of pages to look at

[07:15:03.0000] <annevk>
Philip`, doesn't Y! or some such provide a URL generator?

[07:16:00.0000] <Philip`>
since the results will be significantly biased by however that list is gathered

[07:16:01.0000] <webben>
annevk: a URL generator?

[07:16:02.0000] <webben>
generating based on what?

[07:16:03.0000] <Philip`>
annevk: I couldn't find anyone that had a way of getting a random URL; and random probably isn't very good, since it ought to be weighted towards the pages that people look at frequently

[07:17:00.0000] <Philip`>
(or, couldn't find anyone that had a way of getting a random URL from a sufficiently large collection)

[07:18:00.0000] <annevk>
Lachy, hmm, with html5lib in it? :)

[07:18:01.0000] <Lachy>
possibly

[07:18:02.0000] <webben>
I'm not sure that is necessarily a great way of weighting thing.

[07:18:03.0000] <Lachy>
if it's possible to execute python in an FF extension

[07:18:04.0000] <webben>
e.g. a scientific paper is not necessarily a tiny fraction of the importance of the Digg front page

[07:19:00.0000] <Lachy>
otherwise, it could either use a parser written in JS or just read the DOM from the browser

[07:19:01.0000] <webben>
it's probably a lot more helpful to have different weights by context

[07:19:02.0000] <annevk>
I think that's known webben

[07:19:03.0000] <webben>
e.g. to know that scientific papers tend to use a given sort of markup, and personal homepages another

[07:19:04.0000] <annevk>
If you have a better suggestion please tell it

[07:20:00.0000] <webben>
annevk: Well, one could actually (for example) poll HTML links from connotea or something.

[07:20:01.0000] <Lachy>
the only issue with that would be privacy, since you probably wouldn't want it surveying pages on intranets or in secure sites that the user visits, since it would submit the URI with the data

[07:20:02.0000] <Philip`>
I remember there being one survey done on most of the sites in http://dmoz.org/

[07:20:03.0000] <Philip`>
(Only 'most' because they ran out of time at the end)

[07:21:00.0000] <annevk>
doesn't google base provide some type of index too?

[07:21:01.0000] <webben>
all now dmoz would help categorize stuff

[07:22:00.0000] <webben>
possibly delicious could too

[07:22:01.0000] <Philip`>
Maybe it would be not entirely useless to start with some list of sites, and then make a simple spider so it can get loads more (less biased towards front pages)

[07:22:02.0000] <webben>
Philip`: I suppose you could actually categorize things by the number of / in the URL

[07:22:03.0000] <Philip`>
And perhaps it'd be worthwhile to collect statistics based on lists of pages gathered from different sources, and see how much difference there is between them, to show how much the page selection affects the results

[07:23:00.0000] <webben>
yeah

[07:23:01.0000] <Lachy>
Philip`: if you've got a tool written that I can easily set up and run, I'd be happy to let it run on my computer for a few days straight.  It should be able to get through a 60,000 pages overnight

[07:24:00.0000] <Lachy>
the only issue would be bandwidth

[07:24:01.0000] <Philip`>
You'd probably find it hits that page with a megabyte of numeric entities that make html5lib take quadratic time to parse, and it'd be stuck there for the whole time :-p

[07:26:00.0000] <Philip`>
The 2500 pages I looked at were about 100MB in total, so that's 40KB average, which probably indicates how many you could download

[07:26:01.0000] <annevk>
hmm

[07:27:00.0000] <Lachy>
so 50,000 would be about 2GiB.  That's reasonable

[07:27:01.0000] <annevk>
numeric entity parsing does some conversion stuff that might slow Python down

[07:27:02.0000] <Philip`>
(In a perfect world where I didn't have too many other things to do already, it would be nice to download attached JavaScript and CSS files to see if there's interesting stuff that comes from analysing those)

[07:28:00.0000] <Lachy>
would it be reasonable to disable char ref parsing and just have it emit U+FFFD for all of them?  Would they be relevant to the results?

[07:28:01.0000] <Lachy>
it depends what the survey is looking for

[07:28:02.0000] <Philip`>
annevk: I believe it was the concatenation onto a text node that was quadratic, in the minidom implementation - maybe other tree builders will work better

[07:29:00.0000] <annevk>
oh ok

[07:29:01.0000] <annevk>
so not the actual entity parsing

[07:29:02.0000] <webben>
Lachy: yes you do want to actually read the text (e.g. find out what attributes are use for)

[07:29:03.0000] <webben>
*used

[07:30:00.0000] <Philip`>
It'd probably be good just to have a timeout on the parser

[07:30:01.0000] <Lachy>
webben: yeah, that's why I said it depends what the survey is for.  If it was just to see how many times a particular element occurs, without caring about it's actual content, then it wouldhn't matter

[07:30:02.0000] <Philip`>
I don't expect html5lib is that happy when I try parsing PDF files with it, though at least it didn't break horribly in the cases I encountered

[07:31:00.0000] <Philip`>
(Also, I didn't handle character encoding at all, so I really need to fix that...)

[07:31:01.0000] <webben>
I think information on frequency isn't worth collecting.

[07:31:02.0000] <Lachy>
doesn't it check the MIME and only parse text/html files?

[07:31:03.0000] <webben>
(well, not /just/ frequency anyhow)

[07:34:00.0000] <annevk>
we should check and log Content-Type

[07:35:00.0000] <annevk>
maybe also implement the sniffing for text/html so we can determine whether the page is a feed or not

[07:38:00.0000] <Philip`>
I wasn't checking HTTP headers at all

[07:39:00.0000] <webben>
Lachy: Why would a blank longdesc imply that it's "used incorrectly"? Surely that would just imply there is no long description for the image?

[07:39:01.0000] <Philip`>
though I've got another fork of the downloading script which does save them, since I was looking for mobile sites that actually used XHTML

[07:39:02.0000] <Lachy>
well, it's certainly not used in a useful way

[07:39:03.0000] <webben>
Lachy: That's not the same thing.

[07:39:04.0000] <annevk>
webben, actually, blank means that it references the same URI as the page iirc

[07:40:00.0000] <Lachy>
webben: usefulness is what really matters

[07:40:01.0000] <Lachy>
incorrect values and empty values are both useless

[07:41:00.0000] <webben>
Lachy: Empty values doesn't tell you much about the utility of an attribute.

[07:41:01.0000] <Lachy>
as are links to description pages that aren't really long descriptions of the image

[07:41:02.0000] <Philip`>
An HTML5-compatible web page downloading thing (content-type sniffing, working out charset based on HTTP headers, resolving and following links, etc) in Python would be quite handy

[07:41:03.0000] <Lachy>
an empty value just means that it's a usage that shouldn't be counted as useful

[07:41:04.0000] <webben>
Lachy: What would tell you something is finding web pages with good long descriptions of images and seeing if they make any use of longdesc.

[07:41:05.0000] <webben>
And trying to find out, if they don't, why.

[07:42:00.0000] <annevk>
Lachy, not in theory

[07:42:01.0000] <Lachy>
webben: what the?

[07:42:02.0000] <webben>
(e.g. it might be because they're using <a> links after the image, for reasons of poor UA or AT support)

[07:42:03.0000] <annevk>
<img src> could in theory work if the browser gave a different Accept header when requesting the image resource

[07:42:04.0000] <webben>
or because they got a particular sort of usability advice about it.

[07:42:05.0000] <annevk>
in practice I suppose it doesn't work at all unless there's some base URI

[07:43:00.0000] <webben>
Lachy: In other words, you need to look at examples where longdesc should have (and realistically could have) been used.

[07:43:01.0000] <Lachy>
webben: how would you suggest finding such pages?

[07:43:02.0000] <Lachy>
unless you find them by looking for the presence of the longdesc attribute, you're just looking for a needle in a haystack

[07:44:00.0000] <Lachy>
one example I know of that uses links to long descriptions is the CSS 2.1 spec

[07:44:01.0000] <webben>
Lachy: Well, pages that don't use the longdesc attribute but should have done, or did but used it wrong, are what you're trying to measure. Just looking for the attribute itself doesn't tell you about the former.

[07:45:00.0000] <Lachy>
webben: but then there's still the question of how you find the pages that should have but didn't?

[07:45:01.0000] <annevk>
<base href=foo><img longdesc> would create issues

[07:46:00.0000] <webben>
Lachy: I didn't say it was easy. But there's no point replacing relevant qualitative research with meaningless statistics just because it's easier.

[07:46:01.0000] <webben>
Lachy: I'd be tempted to look at things like British Museum's Compass.

[07:47:00.0000] <webben>
(which probably doesn't use longdesc but i dunno)

[07:47:01.0000] <Lachy>
webben: it really doesn't matter if pages should have used it but didn't, because we're interested in cases where it does get used and get used properly.  Although, pages that don't use it but should have are evidence that the attribute has failed and should be dropped.

[07:47:02.0000] <webben>
i.e. big organizations with disability commitments and interesting images to show

[07:47:03.0000] <Aidan_pl>
I'm have problem with HTML5 

[07:48:00.0000] <webben>
Lachy: They aren't evidence of that necessarily at all.

[07:48:01.0000] <zcorpan>
Aidan_pl: ok

[07:48:02.0000] <Lachy>
then what would they be evidence of?

[07:48:03.0000] <annevk>
Aidan_pl, join the club :)

[07:49:00.0000] <webben>
Given how tied it is to how well or badly a specification specified the attribute, what guidance confused the issue, how poorly UA developers bothered to consider accessibility, how knowledgable and determined AT developers were to get at the attribute anyhow

[07:49:01.0000] <webben>
and the complex interaction of such factors

[07:49:02.0000] <Aidan_pl>
I set doctypelike that: <!DOCTYPE html> and validated  http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fwww.ligagothic.ovh.org%2Findex.php what is wrong?

[07:49:03.0000] <webben>
(there's a lot of feedback in such processes)

[07:49:04.0000] <Lachy>
webben: that would all be evidence of it's failure in the real world

[07:50:00.0000] <webben>
No it wouldn't.

[07:50:01.0000] <Lachy>
yes it would

[07:50:02.0000] <webben>
Why?

[07:50:03.0000] <zcorpan>
Aidan_pl: there's a comment before the doctype. although that is allowed in the spec now.

[07:50:04.0000] <annevk>
Aidan_pl, that's a bug in the validator I believe

[07:50:05.0000] <Lachy>
if it was so poorly specced, poorly implemented, never used, not understood; it has failed.  It's as simple as that!

[07:50:06.0000] <annevk>
Aidan_pl, since the specification is work in progress the validator is not always up to date

[07:51:00.0000] <webben>
Lachy: Well it's true that the process might have failed once. That doesn't mean you can't restart the process in such a way as to succeed.

[07:51:01.0000] <Lachy>
webben: there's no point trying to beat a dead horse

[07:51:02.0000] <webben>
(in fact, failure can often lead to a more successful process the second time round)

[07:51:03.0000] <Lachy>
it ain't going to go anywhere

[07:51:04.0000] <Philip`>
Lachy: Nice choice for selector names ;-)

[07:51:05.0000] <webben>
Lachy: I don't find proverbs to be particularly persuasive.

[07:52:00.0000] <webben>
Lachy: Actually, there's plenty of reasons to expect change in the web sphere.

[07:52:01.0000] <webben>
increasing competition, increasing accessibility awareness among them

[07:52:02.0000] <webben>
rising professional standards

[07:52:03.0000] <Lachy>
webben: a better solution would be to look at the problem that needs to be solved and find a solution that would be successful, instead of trying to drag an unsuccessful solution through.

[07:52:04.0000] <webben>
more digitization of important collections

[07:53:00.0000] <webben>
Lachy: You need to distinguish between the attribute and the process.

[07:53:01.0000] <Lachy>
what the?

[07:53:02.0000] <annevk>
I actually think that <a><img></a> or something similar is better than longdesc

[07:53:03.0000] <webben>
Otherwise your analysis will be hopelessly flawed.

[07:53:04.0000] <annevk>
a description of the image is useful for everyone

[07:54:00.0000] <webben>
annevk: UAs can expose it if they want.

[07:54:01.0000] <webben>
but you don't always want to show the description as a link

[07:54:02.0000] <webben>
annevk: indeed extensions have been written to UAs to expose it

[07:54:03.0000] <annevk>
yes, I'm aware of that

[07:55:00.0000] <webben>
Lachy: there's a huge difference between the conception, the potential of a HTML attribute and the practicalities of getting people using it: the second is a process.

[07:56:00.0000] <webben>
The failure of the process often tells you nothing about the conception or potential of the attribute.

[07:57:00.0000] <Lachy>
the failure of the process tells you everything.  If people still don't use it propelry after 10 years, there's little hope

[07:57:01.0000] <webben>
Lachy: No. It's like the difference between a great invention and actually getting it to market.

[07:57:02.0000] <Aidan_pl>
Is Firefox support to HTML 5?

[07:58:00.0000] <webben>
Market dominance is not linearly correlated with technical excellence.

[07:58:01.0000] <Lachy>
Aidan_pl: it supports some featurs from HTML5 already

[07:58:02.0000] <Lachy>
Aidan_pl: e.g. <canvas>, <a ping="">

[08:00:00.0000] <Lachy>
webben: do you honestly think that longdesc="" is an example of technical excellence?

[08:00:01.0000] <webben>
e.g. the fact that it's taking an absurdly long time to get basic CSS selectors implemented doesn't mean such selectors are hopeless

[08:00:02.0000] <annevk>
Aidan_pl, browsers are incrementally evolving; at some point they will be there

[08:01:00.0000] <webben>
Lachy: I don't see anything wrong with longdesc whatsoever actually. What do you think it's technical flaw is?

[08:01:01.0000] <webben>
I see more problems with alt=

[08:02:00.0000] <webben>
(since you can't indicate changes of language within alt, for instance)

[08:02:01.0000] <Lachy>
it's techincal flaw is that it's an accessibility add-on that requires additional effort from authors, instead of being part of it's fundamental design and use

[08:02:02.0000] <webben>
Lachy: That's not a technical flaw. And it's not surmountable.

[08:02:03.0000] <webben>
Accessibility requires some effort. That is not a technical flaw.

[08:02:04.0000] <webben>
Usability requires some effort. That's not a flaw either.

[08:03:00.0000] <webben>
ditto design etc

[08:03:01.0000] <Lachy>
A good goal is to make accessibility require as little effort as possible to get right

[08:03:02.0000] <webben>
Lachy: Of course. Those aren't contradictory ideas.

[08:03:03.0000] <webben>
Ditto design, usability etc :)

[08:03:04.0000] <webben>
Doesn't mean you can magic away the effort of providing alternatives.

[08:04:00.0000] <webben>
Or the effort of not confusing the user with an overly complicated interface, or of not making your website look ugly.

[08:05:00.0000] <webben>
Computers can't magically describe images for us (yet).

[08:06:00.0000] <webben>
They might one day be able to convert text to sign language and similar transformations though

[08:06:01.0000] <webben>
(there's been some experimentation with S.L. avatars)

[08:09:00.0000] <Aidan_pl>
/me want know is ther any person from poland

[08:16:00.0000] <webben>
"If the alt attribute is omitted, user agents must treat the element as if it had an alt attribute set to the empty string." ... that is not a good idea. UAs should expose the difference between no alt and alt="" to AT.

[08:17:00.0000] <webben>
In the former instance, the AT can do something helpful like try and guess alternative text from the src URI or at least provide the opportunity to label the image.

[08:17:01.0000] <webben>
(this is in fact what AT do now)

[08:18:00.0000] <webben>
although the guessing tends to be a bit rubbish

[08:37:00.0000] <Lachy>
webben: I believe that argument has been made against treating no alt the same as atl="".  Though, I'm not sure why Hixie decided to handle it that way anyway.

[08:37:01.0000] <webben>
it's completely unimplementable AFAICT

[08:38:00.0000] <Lachy>
why?

[08:38:01.0000] <Lachy>
because it would break existing pages?

[08:38:02.0000] <webben>
of course

[08:38:03.0000] <webben>
because that's how AT does handle alt without ""

[08:38:04.0000] <webben>
sorry img with alt

[08:38:05.0000] <webben>
it's not some theoretical process

[08:39:00.0000] <webben>
(and a lot of pages don't have alt attributes)

[08:39:01.0000] <Lachy>
do all ATs do it that way?

[08:39:02.0000] <webben>
all the ATs I've come across do something like that yes

[08:40:00.0000] <webben>
but you can probably configure some to do something different

[08:40:01.0000] <webben>
Lachy: Also it gets a bit more complicated when an img is the sole content for the link

[08:40:02.0000] <webben>
IIRC sometimes the URL of the link will be read instead.

[08:43:00.0000] <Lachy>
how do ATs handle empty links, like <a href="foo"></a>?  I've seen pages do that and then use CSS to size and position them over the top of images to create a sort of image map

[08:44:00.0000] <webben>
Lachy: I don't know. I'd have to test that.

[08:45:00.0000] <webben>
Lachy: http://www.freedomscientific.com/fs_products/Surfs_Up/Custom_Labels.htm example of image labelling with a screen reader

[08:45:01.0000] <webben>
(though that's replacing existing alt text)

[08:45:02.0000] <webben>
ah no it's missing alt text too: "poor, incorrect, or missing ALT text"

[08:55:00.0000] <annevk>
should we add Ajax style stuff to http://html5.org/tools/web-apps-tracker ? as well as maybe integrating the google diff tool thingy?

[08:55:01.0000] <annevk>
might be interesting

[08:59:00.0000] <zcorpan>
bible5, lol :D

[08:59:01.0000] <webben>
Lachy: note that replacing missing alt text (e.g. based on the URI) is actually recommended by UAAG: http://www.w3.org/WAI/UA/UAAG10/guidelines.html#tech-missing-alt

[09:14:00.0000] <zcorpan>
www.whatwg.org isn't very usable with opera mini 4 beta

[09:16:00.0000] <annevk>
reading specs is quite a silly thing to do on a phone though :p

[09:16:01.0000] <zcorpan>
the home page is not a spec

[09:17:00.0000] <annevk>
added bible5

[11:55:00.0000] <zcorpan>
use-case for style="" - plots in a map, like google maps. although perhaps <canvas> is better for that

[11:56:00.0000] <zcorpan>
or svg. dunno

[12:37:00.0000] <Dashiva>
13 hours of no outcry over the selector naming, oh ho

[12:38:00.0000] <zcorpan>
Dashiva: indeed :)

[12:42:00.0000] <Philip`>
/me wonders if it's meant to be possible to say CanvasRenderingContext2D.prototype.fillRect = function () { ... }; canvas.getContext('2d').fillRect() and have it work

[12:42:01.0000] <Philip`>
(That does seem to work in Firefox and Opera, but not in Safari)

[12:42:02.0000] <Philip`>
(but I have no idea where such things would be specified, if anywhere)

[12:43:00.0000] <zcorpan>
Philip`: what, prototypes in general?

[12:44:00.0000] <Philip`>
I'm not sure whether it's a general one, or just specific to that case

[12:48:00.0000] <Philip`>
Hmm, looks like it is kind of specific to that case - I can add to HTMLCanvasElement.prototype in Safari, but the variable CanvasRenderingContext2D doesn't actually exist

[12:49:00.0000] <Philip`>
and getContext('2d').prototype is undefined

[12:52:00.0000] <Dashiva>
zcorpan: Are you installed at Opera yet?

[12:53:00.0000] <Lachy>
I finished writing and revising all examples, cleaned up conformance criteria and various other issues!  I think Selectors API is read to be republished as a WD :-)

[12:54:00.0000] <Dashiva>
Wonder if selectors API will affect gEBCN in html5

[12:55:00.0000] <zcorpan>
Dashiva: yeah

[12:55:01.0000] <Lachy>
dunno.  it seems a bit redundant

[12:55:02.0000] <Dashiva>
zcorpan: Oslo office or somewhere in Sweden?

[12:55:03.0000] <Lachy>
/me wonders if anyone would bother typing getElementsByClassName() when they can type selectAllElements() so much easier

[12:56:00.0000] <zcorpan>
Dashiva: the latter. linköping

[12:56:01.0000] <zcorpan>
Lachy: depends on which is implemented first :)

[12:56:02.0000] <zcorpan>
/me notes that gEBCN is implemented in firefox

[12:56:03.0000] <Lachy>
although, gEBCN would be useful if you have a an array of classnames, selectAllElements() would be useful if you have a selector string

[12:57:00.0000] <zcorpan>
yeah

[12:57:01.0000] <Lachy>
so, it gEBCN has a small use case

[12:57:02.0000] <Dashiva>
I imagine gEBCN also will handle escaping when necessary

[12:57:03.0000] <Lachy>
escaping?

[12:58:00.0000] <Dashiva>
For class names bordering on symbolism

[13:00:00.0000] <Lachy>
Dashiva: I don't understand.  Could you give an example?

[13:01:00.0000] <Dashiva>
Like if someone decides to make a class name containing a period

[13:03:00.0000] <Lachy>
oh, I see.  You're confusing the escapting required in selectors due to the syntax, with a general requirement to escape such characters.  They won't need to be escaped in gEBCN

[13:04:00.0000] <Dashiva>
Well, the result is the same, that you don't have to worry about what your class names are made up of

[13:05:00.0000] <Lachy>
ok

[13:38:00.0000] <Philip`>
Lachy: Is it intentional that the Selectors spec doesn't mention CSS in its first sentence? (I would have thought it ought to, as an effective way of immediately telling people pretty much all they need to know (except the function names) about the API, under the assumption that a reasonable number of people know what CSS selectors are)

[13:40:00.0000] <Lachy>
I couldn't figure out a way to fit a reference to CSS into the intro.  any suggestions?

[13:41:00.0000] <Lachy>
there was a reference to CSS 2.1 in the intro of this revision http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.19&content-type=text/html;charset=UTF-8

[13:41:01.0000] <Philip`>
Maybe "The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors, using the CSS Selectors syntax [Selectors]." or something?

[13:43:00.0000] <Lachy>
no, calling them CSS Selectors is wrong.  But are you suggesting that for the abstract or intro?

[13:44:00.0000] <Philip`>
[Selectors] talks about CSS selectors several times

[13:44:01.0000] <Philip`>
I was thinking of the abstract, since that's the first bit I read and it seems like it should make it clear what 'selectors' actually are

[13:45:00.0000] <Lachy>
maybe something like this...

[13:46:00.0000] <Lachy>
"The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors: the selection syntax that is widely used in CSS"

[13:47:00.0000] <Lachy>
it needs work.  I'll think about it


2007-06-24
[00:52:00.0000] <Lachy>
annevk: yt?

[02:45:00.0000] <zcorpan>
Lachy: in selectors api, using javascript, if resolver returns undefined, is the namespace then the string "undefined"?

[02:46:00.0000] <zcorpan>
Lachy: it seems cumbersome to have to explicitly return the empty string instead of just not bothering and let it return undefined...

[02:47:00.0000] <zcorpan>
or is undefined in javascript equivalent to no return value?

[02:49:00.0000] <zcorpan>
or hmm, actually, nevermind

[02:55:00.0000] <zcorpan>
Lachy: anyway, it seems the spec doesn't contain any conformance requirements for documents, and thus, the conforming documents and conforming authoring tools conformance classes can be dropped

[03:13:00.0000] <annevk>
Lachy, am now

[03:15:00.0000] <annevk>
getElementsByClassName returns a live NodeList btw

[03:15:01.0000] <annevk>
that's a usecase

[03:21:00.0000] <Lachy>
zcorpan: in JS, undefined == null, and the spec defines how to handle null

[03:22:00.0000] <annevk>
however, it's not === null

[03:22:01.0000] <annevk>
until the binding spec covers this you probably need to handle undefined

[03:23:00.0000] <Lachy>
How can I make it clearer that anything that == null, should be treated as null

[03:25:00.0000] <zcorpan>
passing a prefix that is not in the table will return undefined too

[03:25:01.0000] <Lachy>
zcorpan: I already dropped conforming authoring tool.  Were you looking at an old revision?

[03:26:00.0000] <zcorpan>
Lachy: ah. yes.

[03:26:01.0000] <hasather_>
Lachy: the resolver could be rewritten a bit more elegantly:

[03:26:02.0000] <hasather_>
function resolver(prefix) {

[03:26:03.0000] <hasather_>
  return {

[03:26:04.0000] <hasather_>
    "xh": "http://www.w3.org/1999/xhtml",

[03:26:05.0000] <hasather_>
    "svg": "http://www.w3.org/2000/svg"

[03:26:06.0000] <hasather_>
  }[prefix] || "";

[03:26:07.0000] <hasather_>
}

[03:26:08.0000] <Lachy>
I'm not sure if I'll keep "conforming application" in there, that's only there cause there's a few authoring requirements.

[03:27:00.0000] <zcorpan>
given the function above, passing in "foo" as the prefix will return undefined

[03:27:01.0000] <Lachy>
hasather_: yes, it could, but I chose clarity over being a minimalist

[03:27:02.0000] <hasather_>
zcorpan: it will return ""

[03:28:00.0000] <zcorpan>
hasather_: oh, right. ok, given a function in the spec will return undefined

[03:28:01.0000] <Lachy>
oh, I see

[03:29:00.0000] <zcorpan>
an unknown prefix should not get the default namespace

[03:29:01.0000] <zcorpan>
it should raise an exception or something

[03:29:02.0000] <zcorpan>
as in css, the ruleset will be dropped

[03:30:00.0000] <Lachy>
hmm. It doesn't look like I handle returning of empty strings for prefixes in a special way.

[03:30:01.0000] <Lachy>
should I?

[03:32:00.0000] <Lachy>
annevk: I wanted to ask you about this earlier...

[03:32:01.0000] <zcorpan>
if you wanted to declare e.g. xhtml as being the default namespace, it should be possible to say ...{ if (prefix == "") return "http://www.w3.org/1999/xhtml"; } right?

[03:33:00.0000] <Lachy>
It currently says "In doing so, user agents may assume that the object implementing the NSResolver  interface (or ECMAScript Function) only relies on scoped variables, doesn't invoke processes outside the object and returns consistent results when its lookupNamespaceURI method is invoked."

[03:33:01.0000] <Lachy>
in terminology and conventions http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8#terminology

[03:33:02.0000] <annevk>
hmm

[03:34:00.0000] <annevk>
I'd make it as simple as possible for authors with copy & paste samples

[03:34:01.0000] <Lachy>
why should a UA assume scoped variables and not invoking outside processes?

[03:34:02.0000] <annevk>
you could just define that if it returns anything but a non-empty string

[03:34:03.0000] <annevk>
and that null and undefined count as the empty string

[03:37:00.0000] <Lachy>
I'll probably just change that to say this instead, since those other 2 assumptions don't make sense "...user agents may assume that the object implementing the NSResolver interface (or ECMAScript Function) returns consistent results..."

[03:43:00.0000] <Lachy>
hmm. No return value in JS means undefined, not void

[03:53:00.0000] <Lachy>
is there a need for the Interoperability Considerations section to be normative?  I can't see a reason for it, so I'll make it non-normative

[03:59:00.0000] <annevk>
as long as sections don't contain normative keywords you don't really have to mention it

[04:00:00.0000] <Lachy>
I rephrased it and it uses "may", but not really in the RFC2119 sense, so I probably should explicitly state that

[04:00:01.0000] <annevk>
better to replace the use of may I suppose

[04:02:00.0000] <Lachy>
this is what it says now: "Since user agents may optimise the algorithms described in this specification, and because some may invoke the NSResolver object more than others, interoperability concerns may arise if the the NSResolver object (or ECMAScript Function) causes side effects or returns inconsistent results each time it is invoked."

[04:03:00.0000] <Lachy>
any suggestions?

[04:04:00.0000] <annevk>
can arise

[04:04:01.0000] <annevk>
are allowed to optimise

[04:05:00.0000] <Lachy>
that's like what was there before, and I didn't particularly like it

[04:37:00.0000] <zcorpan>
why not make anything that isn't a string (i.e. ===) raise an exception? in particular, undeclared prefixes shouldn't be silently accepted as the default namespace or no namespace

[04:38:00.0000] <zcorpan>
that's not consistent with how it works in css

[04:40:00.0000] <zcorpan>
should i elaborate in an email?

[04:54:00.0000] <zcorpan>
Lachy: yt?

[04:54:01.0000] <Lachy>
yo

[04:55:00.0000] <zcorpan>
see above

[04:55:01.0000] <Lachy>
zcorpan: that's how it does work for prefixes.  Only the default namespace allows you to return undefiend/null/etc.

[04:56:00.0000] <zcorpan>
ah

[04:56:01.0000] <zcorpan>
ok

[04:56:02.0000] <zcorpan>
then it's fine

[04:57:00.0000] <Lachy>
it's a NAMESPACE_ERR exception, see the definition of "unresolvable namespace"

[04:57:01.0000] <zcorpan>
yeah, i see it now

[04:58:00.0000] <zcorpan>
then the function doesn't need to return the empty string for the default namespace, you can just let it return undefined. good. :)

[05:01:00.0000] <Lachy>
yeah, but I'm a perfectionist and I prefer to make it more explicit in the examples

[05:01:01.0000] <Lachy>
though, I'm not sure if it's better to return "" or null?

[05:04:00.0000] <zcorpan>
in the examples?

[05:07:00.0000] <zcorpan>
i think it's better to let it return undefined when you don't want to declare a default namespace. when you do, you use the "" prefix the same way as the other prefixes

[05:10:00.0000] <zcorpan>
function resolver(prefix) {

[05:10:01.0000] <zcorpan>
  var ns = {

[05:10:02.0000] <zcorpan>
    "xh"  :"http://www.w3.org/1999/xhtml",

[05:10:03.0000] <zcorpan>
    "xbl" :"http://www.w3.org/ns/xbl",

[05:10:04.0000] <zcorpan>
    "svg" :"http://www.w3.org/2000/svg",

[05:10:05.0000] <zcorpan>
    "math":"http://www.w3.org/1998/Math/MathML"

[05:10:06.0000] <zcorpan>
  };

[05:10:07.0000] <zcorpan>
  return ns[prefix];

[05:10:08.0000] <zcorpan>
}

[05:10:09.0000] <zcorpan>
if you want to declare xhtml as the default namespace, replace "xh" with ""

[05:10:10.0000] <zcorpan>
and that is the boilerplate

[05:12:00.0000] <zcorpan>
imho

[05:58:00.0000] <Lachy>
should I leave returning an empty string for the default namespace, as meaning no default namespace?

[06:00:00.0000] <Lachy>
hmm. XMLNS says "The empty string, though it is a legal URI reference, cannot be used as a namespace name." -- http://www.w3.org/TR/REC-xml-names/#iri-use

[06:01:00.0000] <Lachy>
perahps I should make the empty string returned for a prefix throw an exception, and leave it as is for the default ns

[06:27:00.0000] <zcorpan>
Lachy: yeah.

[06:33:00.0000] <annevk>
namespaces in XML5 are sort of working

[06:33:01.0000] <annevk>
/me started doing some work on it again

[06:34:00.0000] <annevk>
I should probably make some enhancements to the tokenizer to make <:foo> not work

[06:34:01.0000] <annevk>
<x::> is prolly not that harmful although potentially confusing

[06:37:00.0000] <Lachy>
zcorpan: I adjusted the default NS examples as you suggested

[06:38:00.0000] <zcorpan>
Lachy: checked in?

[06:38:01.0000] <Lachy>
not yet

[06:38:02.0000] <zcorpan>
ok

[06:39:00.0000] <annevk>
if someone can come up with an extension of the html5lib testsuite format that covers namespace, prefix, localname, name, and value (for attributes) that'd be great

[07:20:00.0000] <Lachy>
/me checked in latest changes http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=utf-8

[07:23:00.0000] <annevk>
I'd drop REQUIRED, SHALL and SHALL NOT from the document

[07:23:01.0000] <Lachy>
ok

[07:25:00.0000] <annevk>
also, selectElement returns an Element, not a Node

[07:26:00.0000] <Aidan[pl]>
hi

[07:26:01.0000] <annevk>
the last sample has a newline too much

[07:26:02.0000] <annevk>
Aidan[pl], hi

[07:26:03.0000] <annevk>
maybe s/Informative/Non-normative/

[07:27:00.0000] <Aidan[pl]>
wher can I read more about html5. I searching polish site.

[07:28:00.0000] <Lachy>
annevk: which sample has an extra line?

[07:28:01.0000] <annevk>
not sure about Polish resources

[07:28:02.0000] <annevk>
Lachy, the last one in the document?

[07:28:03.0000] <Lachy>
oh, I see

[07:29:00.0000] <annevk>
is {lookUpNamespaceURI:function(){ ... }} expected to work?

[07:30:00.0000] <Lachy>
yes

[07:30:01.0000] <annevk>
maybe have a sample for that too to make it clear?

[07:30:02.0000] <annevk>
nm

[07:30:03.0000] <Lachy>
it's just syntactic sugar

[07:31:00.0000] <annevk>
what if the object contains more than that member?

[07:31:01.0000] <annevk>
should the spec say something about that much like putImageData has specific requirements

[07:31:02.0000] <Lachy>
it makes no difference

[07:31:03.0000] <Lachy>
/me looks up putImageData

[07:31:04.0000] <annevk>
it currently doesn't, indeed

[07:33:00.0000] <annevk>
the specification doesn't define for instance what to do with objects passed that don't have that method

[07:33:01.0000] <Lachy>
it's better to just ignore any additional methods, which would allow for any future extensions to NSResolver

[07:33:02.0000] <annevk>
euhm

[07:33:03.0000] <annevk>
depends on the extension

[07:35:00.0000] <Lachy>
it sort of does because it says "An unresolvable namespace is a namespace that cannot be resolved because there was no NSResolver provided...", but it could be made more explicit

[07:40:00.0000] <Lachy>
should I also remove RECOMMENDED and OPTIONAL?

[07:40:01.0000] <annevk>
I'd remove everything not used in the spec

[07:41:00.0000] <Lachy>
then MUST NOT and SHOULD NOT can be removed too

[07:41:01.0000] <annevk>
sure

[07:41:02.0000] <Lachy>
"The key words must, should, and may in the normative parts of this document are to be interpreted as described in [RFC2119]."

[07:41:03.0000] <annevk>
nice

[07:42:00.0000] <Lachy>
I think it's ready to be published as a WD now

[07:43:00.0000] <annevk>
did you check in?

[07:43:01.0000] <Lachy>
will do now

[07:44:00.0000] <Lachy>
done

[07:44:01.0000] <Dashiva>
Lachy: The table iteration example could be done a lot easier using the DOM collections. Is the intention just to show gEBTN is clunky?

[07:45:00.0000] <Lachy>
yes

[07:45:01.0000] <Lachy>
which DOM collections?

[07:45:02.0000] <Dashiva>
tBodies, rows, cells

[07:45:03.0000] <annevk>
.rows

[07:45:04.0000] <annevk>
maybe make it an XML table

[07:45:05.0000] <annevk>
<table-row> etc.

[07:45:06.0000] <Dashiva>
If you're ragging on gEBTN, you should also mention it fails to separate between parent and child structures. Like it would grab the tbodies of inner tables too

[07:46:00.0000] <Lachy>
why would I want to do that?  I think the first example should be HTML, since that will be the most common language used with it

[07:46:01.0000] <annevk>
in HTML you don't need gEBTN for what you're doing

[07:47:00.0000] <annevk>
the point Dashiva makes is a good one

[07:47:01.0000] <annevk>
gEBTN only handles descendents where selectElement handles > too

[07:48:00.0000] <Lachy>
I don't see how using .rows could make the example much less verbose

[07:48:01.0000] <Lachy>
I could replace gEBTN("tbody") with .tBodies

[07:48:02.0000] <annevk>
less typing

[07:49:00.0000] <annevk>
and it does something slightly different

[07:49:01.0000] <annevk>
it handles nested tables better

[07:49:02.0000] <Lachy>
the whole example could also be done using XPath .evaluate() too

[07:50:00.0000] <annevk>
I suppose the assumption is that that's not always supported, but HTML APIs are...

[07:50:01.0000] <annevk>
doesn't really matter that much though

[07:59:00.0000] <Lachy>
I could replace the example with this, if that would make you happy:

[07:59:01.0000] <Lachy>
var table = document.getElementById("score");

[07:59:02.0000] <Lachy>
var groups = table.tBodies;

[07:59:03.0000] <Lachy>
var rows = null;

[07:59:04.0000] <Lachy>
var cells = new Array();

[07:59:05.0000] <Lachy>
for (var i = 0; i < groups.length; i++) {

[07:59:06.0000] <Lachy>
  rows = groups[i].rows;

[07:59:07.0000] <Lachy>
  for (var j = 0; j < rows.length; j++) {

[07:59:08.0000] <Lachy>
    cells.push(rows[j].cells[1]);

[07:59:09.0000] <Lachy>
  }

[07:59:10.0000] <Lachy>
}

[07:59:11.0000] <annevk>
you'd have to use child selectors as well than in the selectors sample

[08:01:00.0000] <Lachy>
for the example, child selectors aren't really necessary, since the assumption is that table won't ever contain nested tables, which is a reasonable assumption to make when the author of both table and script is the same

[08:02:00.0000] <annevk>
I suppose that's fair enough

[08:02:01.0000] <annevk>
it would be faster though

[08:03:00.0000] <Lachy>
given that it would be faster, ok

[08:04:00.0000] <zcorpan>
descendant selectors are more convenient than child selectors... and authors are more familiar with descendant than child. not that i feel strongly about it

[08:05:00.0000] <annevk>
they are quite expensive compared to child selectors

[08:05:01.0000] <annevk>
more expensive is a combination of both

[08:06:00.0000] <Lachy>
there are other examples that show descendant selectors used, it's good to give an example with other combinators

[08:06:01.0000] <Lachy>
checked it in

[08:07:00.0000] <Lachy>
how do I get it republished as a WD?  Do I just send a mail to public-webapi and propose it?

[08:07:01.0000] <Lachy>
or maybe to member-webapi?

[08:08:00.0000] <Lachy>
oh, but I should resolve the last remaining open issue in the tracker

[08:08:01.0000] <zcorpan>
"...there are at least two approaches that may be taken." -- although it doesn't really matter, it might be nice to avoid using rfc2119 terms in examples

[08:08:02.0000] <annevk>
you need to generate a new Overview.html

[08:08:03.0000] <Lachy>
yeah, I will do that

[08:09:00.0000] <annevk>
then the best thing is probably to say on public-webapi⊙wo that you want to request publication of a new working draft 1st of july or something and that people have until then to raise issues with that idea

[10:15:00.0000] <Jero>
http://digg.com/design/Crazy_guy_can_draw_using_HTML

[10:15:01.0000] <Jero>
Great example of the power of HTML...

[11:15:00.0000] <webben>
in the current Differences from HTML4 document, this explanation of <b> seems self-contradictory: "The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened."

[11:16:00.0000] <webben>
surely key words in an abstract are given a "typical" typographical presentation of bold in order to convey their "extra importance"

[12:33:00.0000] <Philip`>
http://digg.com/design/Crazy_guy_can_draw_using_HTML

[12:33:01.0000] <Philip`>
Oh, is that the 'paste' button?

[12:34:00.0000] <Philip`>
/me wonders how to copy instead

[12:35:00.0000] <Philip`>
Aha, not by right clicking

[12:39:00.0000] <webben>
"how to copy" with what?

[12:39:01.0000] <Philip`>
With text inside PuTTY

[12:40:00.0000] <webben>
Philip`: select the text then click to paste probably

[12:40:01.0000] <webben>
(on x terms, merely selecting text copies it

[12:40:02.0000] <Philip`>
(I think my computer's graphics card has melted, so I'm stuck on other computers for a while...)

[12:41:00.0000] <Philip`>
Okay - just selecting the text seems to work fine :-)

[13:00:00.0000] <Jero>
I think it'd be nice to have a <content> sectioning element

[13:00:01.0000] <Jero>
it could function as a container element for all the <article>, <section>, <aside> etc. elements

[13:00:02.0000] <zcorpan>
isn't that <body>?

[13:00:03.0000] <Jero>
it could be used as <header><h1>Website</h1><nav/></header><content/><footer/>, which is, IMO, a structure many websites use

[13:01:00.0000] <zcorpan>
(not allowed to have nav in header)

[13:01:01.0000] <Jero>
<header/<nav/><content/><footer/> then (not completely familiar with the spec yet)

[13:01:02.0000] <Jero>
*<header/>

[13:01:03.0000] <zcorpan>
what's in content?

[13:02:00.0000] <Jero>
<article>, <section>, <aside> etc.

[13:02:01.0000] <zcorpan>
what does the content element add beond <header/><nav/><article>, <section>, <aside> etc.<footer/>?

[13:03:00.0000] <zcorpan>
isn't it implicit that things that are not asides or navs are content?

[13:03:01.0000] <mpt>
webben, I've read many document abstracts, and none of them have used bold (or any special style) for their list of keywords

[13:05:00.0000] <Jero>
zcorpan: IMO it just makes sense to group all elements that are content in one <content> element

[13:05:01.0000] <Jero>
(plus it also makes it a lot easier to style using CSS)

[13:05:02.0000] <zcorpan>
Jero: see topic ;)

[13:06:00.0000] <Jero>
>_>

[13:08:00.0000] <zcorpan>
Jero: i'm not saying it's a bad idea, i just haven't heard any convincing use-cases for <content> yet

[13:09:00.0000] <zcorpan>
(i haven't heard convincing use-cases for <footer> either, though)

[13:12:00.0000] <Jero>
/me is brainstorming

[13:14:00.0000] <zcorpan>
/me likes brainstorms

[13:16:00.0000] <mpt>
webben, actually, I think some of them might have used italics, but that would have been for the entire paragraph, including the "Keywords:" intro and all the commas between them

[13:41:00.0000] <webben>
mpt: hence the scare quotes

[13:41:01.0000] <webben>
mpt: If it isn't a common typographical style, that doesn't really make the text better.

[13:48:00.0000] <webben>
zcorpan: Replacing "Skip to main content" links isn't a convincing use case?

[13:48:01.0000] <webben>
(for <content>)

[13:49:00.0000] <webben>
also being able to style it properly

[13:49:01.0000] <webben>
otherwise people are just going to use <div class="content"> anyhow

[13:49:02.0000] <zcorpan>
webben: isn't the first <article> that?

[13:50:00.0000] <webben>
zcorpan: Who knows. (Which is kind of the point.)

[13:50:01.0000] <zcorpan>
what is the main content? isn't it the <article>s?

[13:50:02.0000] <webben>
zcorpan: whatever the author considers to be the main content.

[13:51:00.0000] <Philip`>
Lachy: If I had some comments about the Selectors API (just boring trivial things about indentation and grammar and italicisation), is there somewhere I should put them?

[13:51:01.0000] <webben>
zcorpan: e.g. it might include some introductory text before a list of articles

[13:51:02.0000] <webben>
s/list/series/

[13:53:00.0000] <webben>
it might include a <nav> if the whole point of the page is navigation

[13:54:00.0000] <zcorpan>
like a sitemap?

[13:54:01.0000] <webben>
zcorpan: sitemaps, indexes, tables of contents, lists of stuff

[13:54:02.0000] <webben>
tag clouds

[13:54:03.0000] <webben>
the possibilities are pretty endless

[13:55:00.0000] <webben>
and often might involve explanatory text too

[13:55:01.0000] <zcorpan>
yeah. so what you're saying is that skipping to the first <article> isn't good enough, and that <content> would be more accurate/flexible

[13:56:00.0000] <webben>
zcorpan: yeah that sums it up I guess

[13:56:01.0000] <zcorpan>
good stuff. now forward this information to the list :)

[13:57:00.0000] <webben>
has this been being discussed on the whatwg list?

[13:57:01.0000] <webben>
/me wonders if he missed it in the deluge of list mail he receives daily

[13:57:02.0000] <zcorpan>
what you brought up here is new stuff i think

[13:58:00.0000] <zcorpan>
<content> has been proposed before but it hasn't been explained really what it's use-cases were

[13:58:01.0000] <zcorpan>
(beond <article>)

[13:59:00.0000] <zcorpan>
http://forums.whatwg.org/viewtopic.php?t=35

[14:02:00.0000] <zcorpan>
perhaps "skip to main content" could be implemented by simply ignoring the site-wide header (if any), any <nav>s and any <aside>s. instead of skipping to the first <article>.

[14:04:00.0000] <webben>
zcorpan: Except that the main content might be the nav.

[14:05:00.0000] <zcorpan>
in such a case, couldn't you just not use nav? :)

[14:06:00.0000] <webben>
zcorpan: I think it would be a bit weird to define <nav> as for navigation lists ... except when navigation lists are the main content.

[14:06:01.0000] <zcorpan>
since the main use-case for nav, aiui, is exactly to avoid the need for skip links

[14:06:02.0000] <webben>
As authors are going to want a container for main content anyhow, one might as well use a standard one to make UA's life easier.

[14:06:03.0000] <webben>
zcorpan: Well there are two sorts of skip links

[14:06:04.0000] <webben>
Type 1: skip /to/ somewhere (typically main content)

[14:07:00.0000] <webben>
Type 2: skip /over/ something

[14:07:01.0000] <zcorpan>
right, you can skip to or over a <nav>

[14:08:00.0000] <webben>
zcorpan: well you can skip to or over a paragraph (if UAs bothered to implement such navigation.)

[14:08:01.0000] <webben>
but main content is much more of an authorial judgement

[14:09:00.0000] <zcorpan>
sure

[14:13:00.0000] <Jero>
zcorpan, just look at http://digg.com/

[14:14:00.0000] <Jero>
the "Spreading the Word..." box isn't the main content, the data below that box is

[14:15:00.0000] <zcorpan>
right. that box might be an aside

[14:16:00.0000] <zcorpan>
i agree that there are examples of pages that have an area with "main content" that is not purely an <article> or a series of <article>s

[14:19:00.0000] <Jero>
Hixie, I'd love to hear your opinion on a <content> element

[14:20:00.0000] <zcorpan>
Jero: it would be great if you (or someone else) could summarize this discussion and send it to the list

[14:20:01.0000] <Jero>
also a good idea

[14:20:02.0000] <zcorpan>
Jero: then Hixie will look at it in due course

[14:20:03.0000] <Jero>
i see


2007-06-25
[17:06:00.0000] <Lachy>
Philip`: just send any comments you have to public-webapi

[18:21:00.0000] <Hixie>
Philip`: "CSS Selectors" are selectors used in a css style sheet; the terminology in the selectors spec should be consistent for that

[19:38:00.0000] <Lachy>
Hixie, does XHTML Modularisation serve any purpose beyond splitting up the DTDs?

[19:39:00.0000] <othermaciej>
Lachy: in theory you could reuse XHTML Modules to make your own XHTML subset or to incorporate HTML elements and attributes into a different language

[19:39:01.0000] <Lachy>
othermaciej: I meant practical purposes

[19:39:02.0000] <othermaciej>
I'm not sure what relevance it really has given that DTDs are considered mostly obsolete

[19:39:03.0000] <othermaciej>
Lachy: well, do you consider XHTML Mobile Profile a practical purpose?

[19:39:04.0000] <Lachy>
not really

[19:40:00.0000] <Lachy>
I was just checking, cause that's effectively what I'm about to say in the email I'm about to send

[19:40:01.0000] <othermaciej>
it doesn't have a direct effect on implementations of XHTML per se

[19:40:02.0000] <othermaciej>
it's just a DTD factoring trick

[19:40:03.0000] <othermaciej>
I'm not sure how it even applies to XHTML2

[19:41:00.0000] <Lachy>
I think it applies because the XHTML2 spec refers to chapters as "modules"

[19:42:00.0000] <Lachy>
and because the DTD will be modularised

[19:49:00.0000] <othermaciej>
XHTML2 does not have a DTD

[19:49:01.0000] <othermaciej>
is that planned?

[19:49:02.0000] <othermaciej>
I thought it would be based on a schema language

[19:57:00.0000] <Lachy>
om_out: yes, they are planning a DTD http://www.w3.org/TR/xhtml2/dtd_module_defs.html#a_dtd_module_defs

[20:00:00.0000] <karlUshi>
Lachy: the modularization means you can develop applications for different purposes not only XHTML 2.0 

[20:01:00.0000] <karlUshi>
It means that for example someone who would like to create a specific application for data management in its own company, or a cms

[20:01:01.0000] <Lachy>
you can do that without modules

[20:01:02.0000] <karlUshi>
can use part of XHTML Modules plus other custom defined modules.

[20:01:03.0000] <karlUshi>
without having to reinvent everything

[20:01:04.0000] <karlUshi>
a kind of plug-in architecture.

[20:02:00.0000] <karlUshi>
btw it is not related to DTD per se

[20:02:01.0000] <Lachy>
people have been using HTML in CMSs for years without modules

[20:02:02.0000] <karlUshi>
but to modularization

[20:02:03.0000] <karlUshi>
Lachy: yes and ?

[20:02:04.0000] <karlUshi>
people have been using XML in CMS for years too

[20:02:05.0000] <Lachy>
and so modularisation isn't really necessary for that purpose.

[20:02:06.0000] <karlUshi>
creating their own languages

[20:03:00.0000] <karlUshi>
it is not because Lachy doesn't need it :) that some people don't need it.

[20:04:00.0000] <karlUshi>
which makes me think that I should find the time to update my old list of CMS http://www.la-grange.net/cms   I have 10s of emails in the queue

[20:04:01.0000] <Lachy>
I maintain that modularisation is just a buzzword with little practical benefit.  Hence, the XHTML2 WG's argument that HTML5 doesn't use modularisation is irrelevant

[20:04:02.0000] <karlUshi>
because you are not the main customer of modularization

[20:05:00.0000] <karlUshi>
it's a bit like saying "I'm using my skateboard every day to go to university. I'm a cool kid. I don't need a car. it doesn't have a practical purpose."

[20:06:00.0000] <Lachy>
it's also harmful for those who are.  Just look at the XHTML Mobile Profile, for instance.  It's a complete disaster that only serves to fragment the mobile web from the desktop web

[20:07:00.0000] <karlUshi>
hmmm another debate vi/emacs, pepsi/coke, boring… next.

[20:44:00.0000] <yod>
Hi, I'm a mac... and I'm a Peee ceee 

[00:13:00.0000] <hsivonen>
Hixie: I was away for Midsummer. 

[00:14:00.0000] <hsivonen>
Hixie: I no longer think that a single pass over the HTML document bytes is feasible when meta charset sniffing is needed

[00:15:00.0000] <hsivonen>
Hixie: as for the charset sniffing algorithm vs. using the tokenizer itself, I don't know if the sniffing algorithm is sufficient

[00:15:01.0000] <hsivonen>
let's hope it is

[00:20:00.0000] <hsivonen>
karlUshi: I think XHTML-MP demonstrates that Modularization does not work. WAP Forum did not respect the prescribed module boundaries when they did their thing

[00:21:00.0000] <hsivonen>
karlUshi: making a copy of a monolithic DTD (or another schema) and editing it to taste would have worked

[00:21:01.0000] <Hixie>
hsivonen: well, see the recent changes, let me know if it's ok

[00:26:00.0000] <hsivonen>
Hixie: ok

[00:36:00.0000] <hsivonen>
annevk: the tracker is 500

[01:12:00.0000] <Hixie>
christ, the html list sure is a lot of knee jerking

[01:51:00.0000] <annevk>
hsivonen, I can't reach it at all

[01:53:00.0000] <annevk>
hmm, get it now though

[01:54:00.0000] <annevk>
I wonder what the issue is

[01:55:00.0000] <hsivonen>
/me tries hard going down the versioning rathole again

[01:56:00.0000] <hsivonen>
..to avoid going...

[03:01:00.0000] <annevk>
hsivonen, maybe the problem is that svn.whatwg.org is down

[03:01:01.0000] <annevk>
I'd suggest to use http://dev.w3.org/cvsweb/html5/spec/Overview.html for now

[03:04:00.0000] <annevk>
yeah, the script works fine

[03:04:01.0000] <zcorpan_>
anyone know how to test walk through a range of characters with javascript? e.g. "\u0000" .. "\uFFFF"

[03:04:02.0000] <zcorpan_>
s/test//

[03:06:00.0000] <annevk>
eval("\u" + number) maybe...

[03:09:00.0000] <zcorpan_>
the number will be returned in base 10

[03:09:01.0000] <annevk>
zcorpan_, doesn't JavaScript have a simple way to make a char from an integer?

[03:10:00.0000] <zcorpan_>
i thought it did but i can't find anything

[03:10:01.0000] <hsivonen>
annevk: ok

[03:11:00.0000] <hsivonen>
annevk: you need a four-digit hex string

[03:13:00.0000] <hsivonen>
Number.toString([base])

[03:14:00.0000] <zcorpan_>
ah

[03:15:00.0000] <hsivonen>
zcorpan_: http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:String:fromCharCode

[03:16:00.0000] <zcorpan_>
hsivonen: thanks

[03:52:00.0000] <zcorpan_>
a "development mode" in browsers is not such a bad idea (where the browser complains about non-conforming stuff)

[03:52:01.0000] <zcorpan_>
that can be an extension obviously

[04:12:00.0000] <annevk>
it's called "error console"

[04:18:00.0000] <zcorpan_>
yeah, but i think he had in mind something more agressive

[04:18:01.0000] <zcorpan_>
http://simon.html5.org/test/html/parsing/entities/trailing-semicolon/real/

[04:25:00.0000] <annevk>
I suppose

[04:38:00.0000] <the_mart>
It takes a while to run!

[04:38:01.0000] <zcorpan_>
yes

[04:39:00.0000] <zcorpan_>
though it was surprisingly fast in kestrel

[04:39:01.0000] <zcorpan_>
:)

[04:39:02.0000] <the_mart>
I keep getting “unresponsive script” warnings. ;oþ

[04:40:00.0000] <annevk>
ah, the joys of Firefox

[04:40:01.0000] <annevk>
man, those people complainig about &iuml; should just use the Unicode character directly

[04:40:02.0000] <annevk>
or some character escape

[04:40:03.0000] <annevk>
or whatever we call them now

[04:41:00.0000] <zcorpan_>
004 is fast in safari 3 too

[04:42:00.0000] <the_mart>
I was thinking the same.

[04:44:00.0000] <annevk>
I added "Open Issues": http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html

[04:46:00.0000] <the_mart>
What actually happened to the “summary” attribute on tables?

[04:46:01.0000] <gsnedders>
/me didn't even remember |html|@version existed till I looked at that document

[04:49:00.0000] <annevk>
the_mart, not researched yet

[04:49:01.0000] <the_mart>
Oh.

[04:50:00.0000] <annevk>
It's not really clear to me what it should contain btw. If it's important it should probably be mentioned before the actual table and not be hidden in some attribute...

[04:50:01.0000] <annevk>
And details about the table can be obtained with simple algorithms...

[04:51:00.0000] <the_mart>
Really? I always gave a brief description of the purpose of the table.

[04:51:01.0000] <annevk>
that's my personal pov though, not that of any WG :)

[05:06:00.0000] <zcorpan_>
annevk: a glance of the table, so that you can skip the table altogether

[05:06:01.0000] <mikeday>
Bible5: "Thou SHOULD not kill" <-- what a classic :)

[05:32:00.0000] <hsivonen>
annevk: I trust that Hixie will turn down the backwards-incompatible diaeresis suggestions in due course

[05:32:01.0000] <hsivonen>
/me notes that ä and ö in Finnish don't have German umlaut semantics but people are quite OK with the entity names

[05:34:00.0000] <annevk>
are the actual unicode characters different?

[05:38:00.0000] <zcorpan_>
no

[05:39:00.0000] <annevk>
in that case the argument is silly

[05:39:01.0000] <zcorpan_>
yes

[05:47:00.0000] <hsivonen>
(it would be incredibly stupid to insist on making separate code points for Finnish semantics because the whole point of using the same characters is compatibility with German and Swedish printing hardware)

[05:47:01.0000] <hsivonen>
(same goes for pretty much all European languages whose orthography was influenced by German printing hardware)

[06:12:00.0000] <annevk>
interesting, changed </form> handling in html5lib and again no tests broke

[06:12:01.0000] <annevk>
with over 3000 tests that ran...

[06:13:00.0000] <annevk>
though I suspect that number is not accurate (as some tests are run multiple times)

[06:15:00.0000] <annevk>
8 times

[07:12:00.0000] <met_>
annevk: looking at http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070618/ I cann't find there if onreadystatechange should be raised in sync request or not

[07:23:00.0000] <annevk>
met_, why not?

[07:24:00.0000] <met_>
is it specified? cannot find it

[07:25:00.0000] <annevk>
it's just part of the send() algorithm

[07:27:00.0000] <annevk>
met_, only when sync behavior is different it is mentioned

[07:30:00.0000] <met_>
ok, I was confused

[07:32:00.0000] <met_>
but looks Firefox ignore  onreadystatechange in sync

[07:32:01.0000] <met_>
safari is ok

[07:34:00.0000] <annevk>
that could be true

[07:34:01.0000] <annevk>
browsers are very weird :)

[07:35:00.0000] <met_>
8-)

[07:36:00.0000] <met_>
ok, thanks

[07:36:01.0000] <annevk>
feel free to file a bug on firefox

[07:39:00.0000] <met_>
there are so many reported XHR bugs in FF, this should be probably there alreay, im going to look

[07:40:00.0000] <met_>
/me wonders who is original author of Bible5 text

[07:45:00.0000] <zcorpan_>
<object> needs examples in the spec

[07:45:01.0000] <annevk>
someone needs to write a tutorial

[07:45:02.0000] <zcorpan_>
yeah

[07:46:00.0000] <zcorpan_>
/me writes a wish list to santa

[07:48:00.0000] <Lachy>
can we write to him at santa⊙wo ?

[07:49:00.0000] <annevk>
there's devnull⊙wo

[07:49:01.0000] <Lachy>
has Hixie really set that up?

[07:50:00.0000] <Philip`>
Is that the address of the list moderator?

[07:51:00.0000] <annevk>
your message will get bounced I suppose

[08:13:00.0000] <Lachy>
Philip`: in your email you wrote ""var <var>x</var>" - seems odd to do that for just a few of the variables..."  Are you suggesting that I remove the <var> markup or add it to all of them?

[08:31:00.0000] <met_>
annevk: already there https://bugzilla.mozilla.org/show_bug.cgi?id=313646

[09:32:00.0000] <Philip`>
Lachy: I don't think I have any particular preference either way - it'd just be nicer to be consistent (at least in my opinion), and maybe the easiest way to be consistent is to not use <var> inside the <pre> blocks at all

[09:32:01.0000] <Lachy>
yeah ok, but I'll use it in the prose when referring to the variables

[09:35:00.0000] <Philip`>
Okay, that seems reasonable - it should be clear that <var>x</var> in the prose is referring to the un-marked-up "var x = ..." in the code

[09:35:01.0000] <Philip`>
(Actually, all this stuff is clear anyway without making any changes, if one doesn't insist on being pedantic :-) )

[09:42:00.0000] <Lachy>
Philip`: I insist on being pedantic

[10:00:00.0000] <Philip`>
Lachy: About the 'var' scoping: JS is weird because it doesn't matter where you say "var x" in a function (or how many times you say it) - it always just declares that the current function has a variable 'x' (always initialised to 'undefined'), and it totally ignores any non-function scoping

[10:00:01.0000] <Lachy>
really?  That's weird.

[10:01:00.0000] <Philip`>
so "function f() { x = 1; var x; }" will have a local variable 'x', and won't affect the global variable 'x'

[10:02:00.0000] <Philip`>
I agree it's weird :-)

[10:04:00.0000] <hsivonen>
Hixie: should I expect tokenization changes this week?

[10:04:01.0000] <Lachy>
well, I first learned about variable scope in languages like Java where it works like I described in the email.

[10:04:02.0000] <Philip`>
It's why you get fun stuff like "for (var i = 0; i < 10; ++i) { var j = i*2; setTimeout(100, function () { alert(j) }) }" giving an unexpected value of j, since there's only one j shared by the whole function

[10:05:00.0000] <Philip`>
I believe JS 1.7 adds 'let' which acts like every normal programming language

[10:05:01.0000] <Philip`>
Uh, I think that setTimeout is a bit wrong

[10:07:00.0000] <Lachy>
you got the function and delay reversed

[10:07:01.0000] <Philip`>
/me can never remember which way they go

[10:08:00.0000] <Lachy>
neither can I.  I looked it up.

[12:55:00.0000] <Dashiva>
Is it just me, or do all the accessibility people have giant signatures?

[12:55:01.0000] <gsnedders>
some

[12:55:02.0000] <gsnedders>
of

[12:55:03.0000] <gsnedders>
them

[12:55:04.0000] <gsnedders>
cover

[12:55:05.0000] <gsnedders>
many

[12:55:06.0000] <gsnedders>
lines

[12:56:00.0000] <gsnedders>
(but yes, most seem to, though you can simply tell a screen-reader to stop, so it isn't an accessibility issue)

[13:01:00.0000] <zcorpan_>
Dashiva, quote Is it just me, or do all the accessibility people have giant signatures? unquote yeah.

[13:07:00.0000] <Dashiva>
Oh man, don't get me started on the quote/unquote stuff

[13:07:01.0000] <Dashiva>
I thought top-posting was as bad as it got

[13:18:00.0000] <Jero>
in this piece of code "<nav id=1><nav id=2/></nav>", should #2 be treated as a subnav?

[13:21:00.0000] <zcorpan_>
Jero: the spec just says that <nav> represents a section with navigation links. thus it will be a section with navigation links in a section with navigation links...

[13:26:00.0000] <Jero>
zcorpan_, yeah, but i think there are cases where it'd be convenient if it would

[13:26:01.0000] <Jero>
it would be, for instance, a lot easier to understand the structure of a website

[13:27:00.0000] <zcorpan_>
could you give an example?

[13:27:01.0000] <Jero>
http://tweakers.net/ for instance (sorry, hreflang=nl)

[13:28:00.0000] <zcorpan_>
(dat is ok, ik kan nederlands ;) )

[13:28:01.0000] <Jero>
flex

[13:28:02.0000] <Jero>
the red nav is their main menu and the black nav is the submenu that applies to the selected section

[13:29:00.0000] <zcorpan_>
why not nested <ul>s within the <nav>?

[13:31:00.0000] <Jero>
because i think having a predefined way to discover submenus is better

[13:31:01.0000] <Jero>
when a UA sees a <nav> inside a <nav>, it knows it is submenu

[13:31:02.0000] <zcorpan_>
when a UA sees an <ul> inside an <ul> inside a <nav>, it knows it is a submenu

[13:31:03.0000] <zcorpan_>
?

[13:32:00.0000] <zcorpan_>
what is a UA to do with a submenu?

[13:32:01.0000] <Jero>
because there are a lot of different elements allowed inside the <nav> element, it'd be harder to discover submenus for there are multiple possibilities

[13:32:02.0000] <Jero>
Google for instance

[13:33:00.0000] <zcorpan_>
what is Google to do with a submenu?

[13:33:01.0000] <Jero>
if it wants to spider a website, I think Google (or any other search engine) would like to understand the structure of a website

[13:34:00.0000] <zcorpan_>
right. i don't see why <ul>s don't do the job

[13:35:00.0000] <Philip`>
Or if Google wants to display those useful "About | Download | Screenshots | etc" links on its results page, linking to different specific pages of the top result, where presumably it derives those from the site's structure somehow, perhaps

[13:40:00.0000] <Jero>
zcorpan_: it's hard to find a good argument about the <ul> case because i can't think of any other element that could be used inside a <nav> element to list the pages, but because the spec doesn't limit the content of the <nav> element to <ul> elements, I thought it'd be nice to have a predefined way to discover submenus that works with all possible elements that can be used in <nav> elements.

[13:40:01.0000] <Jero>
Philip`, interesting, but I can't find such links >_> Where can I find them?

[13:41:00.0000] <Philip`>
The multipage HTML5 spec does something roughly like <nav><a href=...>previous page</a> <a>contents</a> <a>next page</a></nav>, as a non-ul example of navs (though I don't know if it's a good example)

[13:42:00.0000] <Philip`>
Jero: Something like http://www.google.com/search?q=lame links to four sub-pages for the first result

[13:42:01.0000] <Jero>
oh interesting

[13:43:00.0000] <Philip`>
and it seems to get the page names via some non-trivial method

[13:55:00.0000] <Jero>
Philip`, yeah, it seems to get the page names from the <title> and/or <h1> elements

[13:55:01.0000] <Jero>
or a combination of the two

[13:56:00.0000] <Philip`>
I'll just attribute it to magic Google dust

[13:58:00.0000] <Hixie>
hsivonen: i already turned down the umlaut thing

[13:58:01.0000] <Hixie>
hsivonen: i don't expect to change the tokeniser this week, in fact i don't really expect to change the spec this week, i want to work on research

[14:00:00.0000] <hsivonen>
Hixie: ok. thanks for the info. do you expect later changes to entity parsing?

[14:09:00.0000] <Hixie>
not particularly, but who knows

[14:09:01.0000] <Hixie>
mostly i expect to change the encoding details

[14:11:00.0000] <hsivonen>
Hixie: ok

[15:07:00.0000] <zcorpan>
"xforms has been designed -- one of the members of the wg was blind himself -- and so now we know it's accessible out of the box. you create your website using xforms and you don't have to do it following any guidelines or anything, it's automatically accessible." -- steven pemberton, http://blip.tv/file/241108

[15:39:00.0000] <Hixie>
zcorpan: one of the members of the html5 wg is blind too

[15:39:01.0000] <Hixie>
same guy, in fact

[15:39:02.0000] <zcorpan>
i don't follow his reasoning though

[15:40:00.0000] <Hixie>
on an unrelated note, i wonder if anyone is going to use the recent thread where chaals explained that xhtml2's target audience was different than html's to argue that xhtml2 should be called something else

[15:40:01.0000] <zcorpan>
not me :)

[15:41:00.0000] <zcorpan>
it doesn't bother me what xhtml2 will be called. so long as the xml serialization of html5 is called xhtml5

[15:42:00.0000] <hsivonen>
/me notes that Java 1.5 became Java5

[15:42:01.0000] <webben>
Hixie: Aren't there (at least) 2 blind members of the HTML5 WG?

[15:42:02.0000] <webben>
Gregory and TV Raman are both members aren't they?

[15:42:03.0000] <Hixie>
oh is Gregory blind too?

[15:43:00.0000] <Hixie>
well then XHTML5 must be TWICE as good as xforms

[15:43:01.0000] <zcorpan>
LOL

[15:43:02.0000] <Hixie>
i really pity anyone who has to use jaws, btw

[15:43:03.0000] <webben>
Hixie: don't forget that we don't really know how to use it

[15:44:00.0000] <Hixie>
how do you mean?

[15:44:01.0000] <webben>
Hixie: The way people who use AT all the time use it is different to the way casual web developers tend to use it.

[15:44:02.0000] <zcorpan>
yeah

[15:44:03.0000] <Hixie>
my problems with jaws are far more fundamental

[15:45:00.0000] <webben>
While screen readers are pretty awful, I don't think they're dramatically worse than UAs to begin with.

[15:45:01.0000] <Hixie>
let's see if i can get it running again, hold on

[15:45:02.0000] <webben>
Hixie: Ah ... yeah for the performance problems like that you'd have to blame application authors

[15:46:00.0000] <webben>
(for not using accessibility frameworks ... hence necessitating JAWS to fake being a video driver)

[15:46:01.0000] <zcorpan>
i've heard that you have to use a screen reader with the monitor turned off for at least 3 weeks to have an idea of what it's like

[15:46:02.0000] <webben>
e.g. Safari for Windows doesn't use native controls and doesn't expose to MSAA (for the actual web content)

[15:46:03.0000] <webben>
it's that sort of thing which has made AT's life really difficult

[15:47:00.0000] <Hixie>
how the hell do i get jaws to talk again

[15:47:01.0000] <webben>
(also MSAA is old and sucky)

[15:47:02.0000] <webben>
Hixie: why did it stop?

[15:47:03.0000] <webben>
/me didn't have big performance problems when experimenting with JAWs 7.1

[15:47:04.0000] <Hixie>
i closed it one time and it has never spoken since

[15:47:05.0000] <Hixie>
i've no idea why

[15:48:00.0000] <webben>
since, meaning at all ever, or in this windows session?

[15:48:01.0000] <Hixie>
at all ever since the last time i closed it

[15:48:02.0000] <Hixie>
running the jaws program brings up this window with their logo but does nothing else

[15:49:00.0000] <webben>
Hixie: do you have any other readers installed?

[15:49:01.0000] <Hixie>
nope

[15:49:02.0000] <webben>
Hixie: I'd post a quick message to one of the JAWS's mailing lists. A regular user would probably know what to do.

[15:50:00.0000] <webben>
Hixie: does JAWS respond to commands (e.g. does the link list open)

[15:50:01.0000] <Hixie>
how do i get that up again? my manual's in the other building

[15:50:02.0000] <webben>
Hixie: the JAWS manual is available for download

[15:50:03.0000] <Hixie>
let me try logging out and back in again

[15:50:04.0000] <webben>
(in an exe file, which unloads to chm, bleh)

[15:52:00.0000] <othermaciej>
zcorpan: we'll probably fix accessibility in time, it just didn't make the cut for the beta

[15:52:01.0000] <Hixie>
ooo

[15:52:02.0000] <Hixie>
that helped

[15:53:00.0000] <Hixie>
wow, jaws doesn't handle putty well

[15:53:01.0000] <Hixie>
it just says "exclaim" over and over

[15:53:02.0000] <Hixie>
anyway

[15:53:03.0000] <Hixie>
let's see how it handles my blog

[15:53:04.0000] <webben>
Hixie: online docs: http://www.freedomscientific.com/fs_support/doc_screenreaders.asp

[15:53:05.0000] <webben>
(useful PDF of keyboard shortcuts at top)

[15:54:00.0000] <webben>
http://www.freedomscientific.com/fs_products/Surfs_Up/_Surfs_Up_Start_Here.htm also useful if you haven't seen it

[15:55:00.0000] <webben>
Hixie: INS + F7 to list links (on a standard desktop PC keyboard with the standard JAWS layout)

[15:56:00.0000] <Hixie>
i love that when i hit a page with an http auth dialog, while the dialog is waiting for me to log in, IE keeps saying "25%. 26%. 27%."

[15:57:00.0000] <hsivonen>
/me notes that JAWS documentation uses <b>

[15:57:01.0000] <webben>
hsivonen: Screen reader developers are not experts in the HTML domain.

[15:57:02.0000] <webben>
their websites are generally awful

[15:57:03.0000] <webben>
(NVDA and Raman's being honourable exceptions IIRC)

[15:58:00.0000] <hsivonen>
webben: does <b> make their site horrendously inaccessible compared to <strong>?

[15:58:01.0000] <webben>
hsivonen: No, no. I'm talking about their authoring practices generally.

[15:59:00.0000] <webben>
the common failure to provide docs in HTML format is kind of a giveaway

[15:59:01.0000] <webben>
window-eyes provides HTML docs ... in a frameset

[16:00:00.0000] <Hixie>
I love how it reads my blog. "The CSS working group is irrelevant back in March. Google host the CSS working group for a three day meeting."

[16:02:00.0000] <webben>
Hixie: if you want more differentiation between elements try the web-rent-a-crowd scheme

[16:02:01.0000] <webben>
(or turning on more announcements if you prefer that to voice changes)

[16:02:02.0000] <Hixie>
hm?

[16:03:00.0000] <Hixie>
"web-rent-a-crowd?

[16:03:01.0000] <Hixie>
"

[16:03:02.0000] <webben>
Hixie: Yeah ... this is why it grates that FS don't provide docs in HTML format

[16:03:03.0000] <Hixie>
what's "web-rent-a-crowd"?

[16:03:04.0000] <webben>
Hixie: JAWS has various schemes for how it reads things. Web RentACrowd is one of them.

[16:03:05.0000] <Hixie>
where do i find that?

[16:03:06.0000] <webben>
basically different elements are read in different voices

[16:03:07.0000] <webben>
hang on

[16:04:00.0000] <webben>
Hixie: I happen to have instructions here: http://www.benjaminhawkeslewis.com/www/accessibility/q-element/q-and-screen-readers#jaws

[16:04:01.0000] <Hixie>
cool

[16:06:00.0000] <Hixie>
holy jesus this is the least usable configuration system i've ever used

[16:06:01.0000] <Hixie>
maybe excluding .emacs

[16:06:02.0000] <webben>
Hixie: Well it is like emacs in that a lot of it will be accessed by keyboard shortcuts

[16:07:00.0000] <webben>
I think the shortcuts can be faster than navigating through one config window after another

[16:07:01.0000] <Hixie>
i meant ".emacs"

[16:07:02.0000] <Hixie>
as in the .emacs configuration file

[16:07:03.0000] <webben>
oh i see

[16:07:04.0000] <Hixie>
i have no idea what most of these settings mean

[16:07:05.0000] <Hixie>
Text Block Length: [ 25 ]

[16:07:06.0000] <webben>
Hixie: Ah I know that one.

[16:08:00.0000] <webben>
Hixie: Basically, JAWS offers a facility for skipping over grouped links.

[16:08:01.0000] <webben>
by looking for text that is not a link and is a certain length

[16:08:02.0000] <webben>
I think that's what it means

[16:08:03.0000] <webben>
25 is (probably) characters

[16:08:04.0000] <Hixie>
yeah i worked it out from the help screen

[16:08:05.0000] <Hixie>
but that's still horrendous ui

[16:08:06.0000] <Hixie>
that option shouldn't exist

[16:11:00.0000] <webben>
Hixie: Other than their failure to put it online in a form where you can refer people to it, FS's documentation is actually not too bad. I've just been trying to deal with Dolphin's documentation to see if it's at all possible to get HAL to do something with longdesc, but their manual is kinda hopeless.

[16:11:01.0000] <Hixie>
their documentation is ok, yeah

[16:11:02.0000] <Hixie>
their actual ui is horrid

[16:11:03.0000] <webben>
You'll get like a configuration dialog full of cryptic options, and the help will be a confusing summary of what the window is for, rather than a breakdown of the different options.

[16:12:00.0000] <webben>
Hixie: In all fairness, the UI is inevitably going to be fairly complex.

[16:12:01.0000] <webben>
/me is trying to design part of the UI for Orca atm; it's non-simple.

[16:12:02.0000] <Hixie>
why?

[16:13:00.0000] <webben>
Hixie: Partly because people have very different software, very different needs, and very different preferences.

[16:13:01.0000] <webben>
(e.g. different synths/voices capable of different things, different combinations of braille/speech use, differing ideas about verbosity)

[16:13:02.0000] <Hixie>
that doesn't explain why the user can decide how many characters to look for when skipping to the next non-link

[16:13:03.0000] <webben>
and want different things at different times.

[16:14:00.0000] <webben>
Hixie: It's possible that can be set on a site-by-site basis.

[16:14:01.0000] <webben>
where it might well be useful

[16:15:00.0000] <Hixie>
well rent-a-crowd worked, but it's buggy as hell

[16:15:01.0000] <webben>
buggy?

[16:16:00.0000] <Hixie>
e.g. (<a href="">Foo</a>)  reads as (voices denoted by case):   "left paren VISITED FOO RIGHT PAREN"

[16:16:01.0000] <Hixie>
wrong voice for the right paren

[16:16:02.0000] <Hixie>
also, it's still horrible to use

[16:16:03.0000] <webben>
hmm

[16:16:04.0000] <webben>
Hixie: If you have a licenced copy, you could submit them a test-case for that.

[16:17:00.0000] <webben>
(They'll prove ultimately unhelpful if you're just using an evaluation version.)

[16:17:01.0000] <Hixie>
when you're reading a book to someone (e.g. an audio book) you don't say "heading" before every heading

[16:17:02.0000] <Hixie>
i have a licensed copy

[16:17:03.0000] <Hixie>
thanks to google

[16:17:04.0000] <webben>
cool :)

[16:17:05.0000] <Hixie>
where's the bug database?

[16:17:06.0000] <webben>
Hixie: You have to email technical support. Like Opera.

[16:17:07.0000] <Hixie>
i have an opera bug system account

[16:17:08.0000] <Hixie>
and opera's bug system has a public facing bug entry page, too, for those who don't

[16:18:00.0000] <webben>
hmm IIRC FS just have email

[16:18:01.0000] <Hixie>
who the hell says "left paren" "right paren" all the time, christ

[16:18:02.0000] <Hixie>
i'm going to go batty using this

[16:19:00.0000] <webben>
http://www.freedomscientific.com/fs_about/Contact_Us_Form.asp?Mail_Subject=Support

[16:19:01.0000] <webben>
Hixie: you need to reduce your verbosity settings for punctuation

[16:19:02.0000] <webben>
Hixie: most SR users do; then they increase it temporarily when they need it for something

[16:19:03.0000] <webben>
(e.g. coding)

[16:20:00.0000] <Hixie>
do i want SAPI5 or not?

[16:20:01.0000] <webben>
Hixie: I'm not an expert on voices; this is another thing where people have preferences; supposedly Eloquence is quite good.

[16:20:02.0000] <Hixie>
that's what i'm using

[16:20:03.0000] <Hixie>
it's not SAPI5

[16:20:04.0000] <webben>
no SAPI5 is the Microsoft voices

[16:21:00.0000] <webben>
like Sam

[16:21:01.0000] <webben>
(or at least SAPI5 is the MS synth and comes with some MS voices)

[16:21:02.0000] <webben>
i think other companies also produce other SAPI5 voices

[16:21:03.0000] <Hixie>
yeah i have a bunch apparently

[16:22:00.0000] <webben>
people tend to assume that SR users want naturalistic voices; but since many of them speed them up so that they are almost unrecognizable to the untrained ear that's not necessarily true

[16:22:01.0000] <Hixie>
oh thank god, i've found how to kill the punctuation

[16:23:00.0000] <webben>
Hixie: what version are you using btw?

[16:24:00.0000] <Hixie>
why does it keep saying "graphic" before <img> elements with alt="" text, grr

[16:24:01.0000] <Hixie>
8.0

[16:24:02.0000] <Hixie>
just got it last week

[16:24:03.0000] <webben>
Hixie: are they inside links?

[16:24:04.0000] <Hixie>
yes

[16:24:05.0000] <webben>
Hixie: Yeah, there's been quite a lot of criticism of 8.0's stability on the lists.

[16:24:06.0000] <Hixie>
though it doesn't say _that_

[16:24:07.0000] <webben>
Hixie: are they the sole content of the links?

[16:25:00.0000] <Hixie>
e.g. the ? icon at the top of the html5 spec

[16:26:00.0000] <webben>
Hixie: that has alt="WHATWG"

[16:26:01.0000] <webben>
oh I see you mean alt text not alt=""

[16:27:00.0000] <Hixie>
right

[16:27:01.0000] <webben>
yeah that's normal

[16:27:02.0000] <webben>
you can probably turn it off

[16:27:03.0000] <webben>
but it can be useful to know things are an image

[16:27:04.0000] <Hixie>
wow, it screws up the rendering of the <dl> at the top of hte spec, too

[16:27:05.0000] <webben>
yeah dl dd dt supposedly don't work too well in JAWS ... I've never tested that though

[16:28:00.0000] <webben>
would be interesting to see what IE does with them in MSAA though

[16:28:01.0000] <Hixie>
brb going to my office


2007-06-26
[18:16:00.0000] <Hixie>
well i was going to do some research of year-based data based on Last-Modified headers, but most pages don't actually serve them

[18:16:01.0000] <Hixie>
so that's gone out of the window

[18:18:00.0000] <kingryan>
Hixie: have you thought of using the wayback machine?

[18:18:01.0000] <kingryan>
from archive.org?

[18:18:02.0000] <Hixie>
how?

[18:19:00.0000] <kingryan>
they make their data available to researchers

[18:19:01.0000] <kingryan>
they have indexes from crawls by alexa that are roughly every 6 months since about 1994

[18:19:02.0000] <kingryan>
if you want to do comparative study based on time, you could use those buckets

[18:21:00.0000] <Hixie>
it's not clear to me that their system could support parsing every single file in their index

[18:21:01.0000] <kingryan>
I think it'd only be possible through the alexa web search apis

[18:22:00.0000] <Hixie>
yeah, that's not really enough for what i want to do

[18:22:01.0000] <Hixie>
(find how element usage varies over time)

[18:22:02.0000] <Hixie>
(and class, and id)

[18:22:03.0000] <kingryan>
yeah, you're probably right

[18:25:00.0000] <Hixie>
so i scanned about 100,000 documents (not really at random, so this may not be representative)

[18:25:01.0000] <Hixie>
about 100,000 of them had no last-modified headers

[18:25:02.0000] <Hixie>
about 20000 of them said 2007

[18:25:03.0000] <Hixie>
1 of them said 200 AD

[18:26:00.0000] <Hixie>
oh i see, it actually said Tue, 14 Oct 02003 06:53:14 GMT

[18:26:01.0000] <bewest>
heh. wise guy, eh?

[18:26:02.0000] <othermaciej>
served from a stone tablet?

[18:26:03.0000] <Hixie>
1 said 2044

[18:26:04.0000] <Hixie>
a number said 2099

[18:27:00.0000] <Hixie>
and a spanish one said Mon, 26 Jul 2250 05:00:00 GMT

[18:27:01.0000] <kingryan>
maybe we need to define Time5

[18:27:02.0000] <kingryan>
or Calendar5

[18:27:03.0000] <Hixie>
there's also a number of files from 1971 to 1994

[18:27:04.0000] <Hixie>
which is impressive since the web started in 1990

[18:28:00.0000] <Hixie>
but not impossible

[18:28:01.0000] <Hixie>
wow some of them aren't even joking

[18:28:02.0000] <Hixie>
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=4803661&dopt=Abstract

[18:28:03.0000] <Hixie>
^ 1973

[18:29:00.0000] <kingryan>
I suppose that be an accurate LM header then

[18:29:01.0000] <Hixie>
looks like all the 1971-1979 dates are from nih.gov

[18:30:00.0000] <Hixie>
and this one from 1985 actually redirects to nih.gov heh

[18:38:00.0000] <Hixie>
spec says you MUST use GMT

[18:38:01.0000] <Hixie>
apparently some people in europe didn't understand what MUST means

[18:38:02.0000] <Hixie>
also what kind of date is "Mon, 22 Jan 2007 23:21:22 GMT,Tue, 07 Feb 2006 09:16:47 GMT" ??

[18:39:00.0000] <Hixie>
wow, all kinds of random formats are used

[18:39:01.0000] <Hixie>
sheesh

[18:39:02.0000] <Hixie>
how hard can this be

[18:39:03.0000] <Hixie>
"{ts '2007-04-29 03:40:38'},{ts '2007-04-29 03:40:38'}" is NOT a valid Last-Modified date!

[18:39:04.0000] <Hixie>
come on people!

[18:50:00.0000] <Hixie>
in my sample of 100000 or so files, there were about 1000 unique _formats_

[18:50:01.0000] <Hixie>
for the date

[18:51:00.0000] <kingryan>
 any valid ones?

[18:51:01.0000] <Hixie>
there are only three valid formats per the spec, which would come up as 10 or so the way i counted it

[18:51:02.0000] <Hixie>
so that's about 990 invalid ones

[18:52:00.0000] <kingryan>
and you said "so i scanned about 100,000 documents" and "about 100,000 of them had no last-modified headers"

[18:52:01.0000] <kingryan>
I'm guessing one of those is off by an order of magnitude

[18:52:02.0000] <Hixie>
actually no

[18:52:03.0000] <Hixie>
i was _about_ 100,000 files, and _about_ 100,000 of them had no date

[18:52:04.0000] <Hixie>
both numbers to 1sf

[18:52:05.0000] <kingryan>
gotcha

[18:53:00.0000] <Hixie>
actual numbers were closer to 140000 and 100000, i think

[21:33:00.0000] <Hixie>
wtf is up with svn.whatwg.org

[22:04:00.0000] <Hixie>
http://junkyard.damowmow.com/283

[22:04:01.0000] <Hixie>
not very scientific

[22:05:00.0000] <Hixie>
but that seems to be the distribution of years in the Last-Modified headers

[22:05:01.0000] <Hixie>
on the web

[22:41:00.0000] <Lachy>
wow, I wasn't aware the google bot had access to all web pages in space and *time*! It'd be interesting to see what's in the pages that were last modified in 2250, just to get a glimpse of the future ;-)

[22:43:00.0000] <Hixie>
:-)

[22:43:01.0000] <Hixie>
see #whatwg for background on those numbers

[22:43:02.0000] <Hixie>
wait this is #whatwg

[22:43:03.0000] <Hixie>
aaah

[22:43:04.0000] <Hixie>
confusing

[22:43:05.0000] <Lachy>
lol

[22:44:00.0000] <Lachy>
should I check the logs from past or future discussion?

[22:44:01.0000] <Hixie>
hah

[22:44:02.0000] <Hixie>
last block of the logs (when i was talking to ryan)

[02:05:00.0000] <hsivonen>
I wonder if 1969 is actually meant to be 1970-01-01 but time zones make it fall in 1969-12-31

[02:05:01.0000] <hsivonen>
I would have expected to see numbers since 1992 and a peak in 1970

[02:06:00.0000] <hsivonen>
the data points in between and before are surprising

[02:07:00.0000] <othermaciej>
I thihnk the default date on macintosh systems was 1969 at one point

[02:10:00.0000] <Hixie>
the numbers from 1971 to 1990 are intentional -- i spot checked some and they were of a site that made articles from those years available

[02:10:01.0000] <annevk>
Lachy, svg:svg is not a selector

[02:10:02.0000] <annevk>
Lachy, its svg|svg

[02:10:03.0000] <Lachy>
oops

[02:10:04.0000] <annevk>
Lachy, which would be a SYNTAX_ERR in IEs case

[02:11:00.0000] <Hixie>
i suppose i'd better actually implement all the spec changes i made recently

[02:11:01.0000] <annevk>
Lachy, because they don't support namespaces...

[02:12:00.0000] <Lachy>
they can add sufficient support for namespaces in selectors to at least understand the syntax, they just don't have a DOM with namespaces

[02:14:00.0000] <annevk>
they actually do... sort of

[02:15:00.0000] <Lachy>
yeah, they sort of do with xml data islands and stuff, but that's their mess to sort out

[02:17:00.0000] <hsivonen>
Lachy: their mess is generally ours to sort out

[02:46:00.0000] <Hixie>
http://junkyard.damowmow.com/284

[02:47:00.0000] <Hixie>
i wonder what all the low numbers are

[02:47:01.0000] <Hixie>
other than the timezone ones

[02:47:02.0000] <Hixie>
and what's with the hundreds of pages in the early 1900s?

[02:48:00.0000] <Hixie>
i wonder if a few million pages per year is enough to get decent trends data on element class and ID usage

[02:49:00.0000] <Hixie>
there are more pages that claim to be from 2008 than from 1991

[02:49:01.0000] <Hixie>
given how unlikely it is for a page to be from 2008, i wonder what tells us about the pages that claim to be from 1991

[02:51:00.0000] <Hixie>
time to go home

[02:51:01.0000] <Hixie>
i love how there's a spike at 2038 (max 32bit time_t)

[02:54:00.0000] <zcorpan>
http://mrclay.org/index.php/2007/06/25/kill-these-dom0-shortcuts/

[02:55:00.0000] <Hixie>
zcorpan: yeah, saw that. i wonder what we should do. we could deprecate those names, but it seems like a slippery slope.

[02:56:00.0000] <othermaciej>
you could make use of them nonconforming, but then suddenly you have conformance criteria on scripts

[02:56:01.0000] <zcorpan>
browsers can log overwrites in the error console

[02:56:02.0000] <zcorpan>
well, <form name> is already non-conforming

[02:56:03.0000] <othermaciej>
the special names don't always take precedence over built-in properties

[02:56:04.0000] <Hixie>
anyway

[02:56:05.0000] <zcorpan>
oh

[02:56:06.0000] <Hixie>
going home now

[02:56:07.0000] <Hixie>
later all

[02:57:00.0000] <zcorpan>
/me waves

[02:57:01.0000] <annevk>
g'night

[02:57:02.0000] <othermaciej>
I mean depending on the object

[02:57:03.0000] <othermaciej>
for HTMLFormElement they do

[02:57:04.0000] <othermaciej>
which is sad

[02:57:05.0000] <zcorpan>
<input name=submit>

[02:58:00.0000] <othermaciej>
for the remaining elements where name is allowed, you could make use of names that conflict with built-in DOM properties nonconforming

[02:58:01.0000] <zcorpan>
yeah

[02:58:02.0000] <othermaciej>
but then there are some things that do special lookup like this by id too

[03:01:00.0000] <othermaciej>
the things in WebKit that have overriding get-by-name in WebKit are HTMLFormElement, HTMLFrameSetElement, HTMLObjectElement, HTMLEmbedElement, HTMLAppletElement and HTMLDocument

[03:01:01.0000] <othermaciej>
not sure if this is a complete list

[03:01:02.0000] <othermaciej>
(Window lookup by name is non-overriding I think)

[03:12:00.0000] <Lachy>
I don't get why Robert Burns thinks dropping <img> and <embed> in favour of a new element would work.

[03:12:01.0000] <Lachy>
he seems to be thinking entirely about accessibility and fallback, and ignoring every other issue like backwards compatibility

[03:13:00.0000] <Lachy>
and the fact that replacing <img> with <object> was already tried and mostly failed

[03:15:00.0000] <kfish>
Lachy, some people just like abstractions for the sake of abstraction :-)

[03:15:01.0000] <kfish>
whereas others prefer clarity for the sake of clarity

[04:03:00.0000] <Hixie>
i wonder if robin misunderstood lachy's e-mail

[04:04:00.0000] <annevk>
I believe he wants them to be case-sensitive

[04:05:00.0000] <Hixie>
in which case he misunderstood the e-mail

[04:05:01.0000] <annevk>
fair enough

[04:22:00.0000] <Lachy>
/me goes to respond to Robin to clarify it for him

[04:33:00.0000] <Jero>
"...but no start tag token has ever been emitted by this instance of the tokeniser (fragment case)..." This simply means the stack is empty, right?

[04:34:00.0000] <annevk>
if that's what it means it would be better if the spec said that...

[04:35:00.0000] <Jero>
well I'm not sure if that's what it means, but it basically seems like it does

[04:36:00.0000] <Jero>
should I send Hixie an email?

[04:38:00.0000] <annevk>
why not

[04:38:01.0000] <annevk>
I suppose it might be a while to get an answer so I'd just go ahead with something and test it

[04:38:02.0000] <annevk>
maybe compare with html5lib

[04:40:00.0000] <Jero>
is it completely up to date?

[04:40:01.0000] <annevk>
was this a recent change?

[04:40:02.0000] <annevk>
I'm not sure if it's up to date with fragment parsing per se

[04:41:00.0000] <Jero>
I'm working on revisions 908 till 960

[04:41:01.0000] <Jero>
though I'm not sure in which revision this change was made

[04:42:00.0000] <annevk>
I made most of those, didn't see fragment cases though

[04:43:00.0000] <Jero>
hmm ok

[04:43:01.0000] <Jero>
I'll just send Hixie and interpret it as "...if the stack of open elements is empty..." for now

[04:44:00.0000] <annevk>
alternatively you could test browsers

[04:44:01.0000] <Jero>
hmm yeah

[04:44:02.0000] <Jero>
i'll do a couple of tests

[04:57:00.0000] <Jero>
actually it's quite logical, if no start tag has been omitted, then there's no reason to check if the closing tag is the closing tag for the element that triggered the (R)CDATA state

[04:57:01.0000] <Jero>
thus checking if no start tag has been omitted is practically the same to check if the stack is empty

[05:37:00.0000] <annevk>
hsivonen++

[05:46:00.0000] <zcorpan>
would i send email to xml-names-issues⊙wo for bugs in the namespaces in xml 1.0 spec?

[05:57:00.0000] <annevk>
would or should?

[05:58:00.0000] <hsivonen>
zcorpan: what bug?

[05:59:00.0000] <hsivonen>
I think I've finally gotten the byte stream decoding right

[05:59:01.0000] <hsivonen>
whew. that was hard

[06:00:00.0000] <hsivonen>
and I only solved the cases that are needed for my tokenizer. a general-purpose InputStreamReader substitute would be even harder

[06:05:00.0000] <Lachy>
/me throws a tomato at hsivonen :-P

[06:06:00.0000] <annevk>
hsivonen, to properly handle unicode?

[06:10:00.0000] <Jero>
Why can the "DOCTYPE public/system identifier (single/double-quoted) state" not be combined with the "Before DOCTYPE public/system identifier state"?

[06:10:01.0000] <Jero>
the QUOTATION MARK case could simple say "get all characters until the next QUOTATION MARK or EOF character"

[06:11:00.0000] <Jero>
same for the APOSTROPHE case

[06:11:01.0000] <annevk>
because that's not the way the rest of the states work (such as attribute values)

[06:12:00.0000] <annevk>
you could implement it that way though

[06:12:01.0000] <Jero>
right, but the same would also apply to the attribute values then, right?

[06:12:02.0000] <annevk>
well, attribute values special case & too for obvious reasons

[06:13:00.0000] <Jero>
oh yeah, that's right

[06:13:01.0000] <hsivonen>
annevk: to properly decode a byte stream into char[] while using a decoder API that I didn't design, recovering from error, reporting errors at the same time and keeping track of the 512 byte boundary

[06:14:00.0000] <annevk>
is char[] unicode aware in Java?

[06:14:01.0000] <annevk>
yeah, it is iirc...

[06:14:02.0000] <hsivonen>
annevk: char[] is an array of UTF-16 code units

[06:15:00.0000] <Jero>
annevk: but then again, why should the DOCTYPE states not be changed because the other states don't work that way? It's not like they conflict with eachother

[06:15:01.0000] <annevk>
so not necessarily 16 bits, right?

[06:15:02.0000] <hsivonen>
annevk: char[] is an array of unsigned 16-bit values

[06:15:03.0000] <the_mart>
It only supports the BMP though.

[06:15:04.0000] <annevk>
Jero, I like the current way better... It's just a way of writing things done. not worth debating too much about I think

[06:16:00.0000] <Jero>
true

[06:16:01.0000] <hsivonen>
the_mart: what supports only the BMP?

[06:16:02.0000] <the_mart>
char in Java.

[06:16:03.0000] <annevk>
hsivonen, so what about code units that require more than 16 bits? I believe they exist...

[06:16:04.0000] <hsivonen>
the_mart: char yes, but char[] supports astral planes if you use it right

[06:17:00.0000] <annevk>
BMP?

[06:17:01.0000] <hsivonen>
annevk: UTF-16 code units are always 16 bits. code points that don't fit in 16 bits are handles as two code units

[06:17:02.0000] <hsivonen>
annevk: Basic Multilingual Plane

[06:18:00.0000] <annevk>
ah, code points

[06:18:01.0000] <annevk>
that makes sense

[06:18:02.0000] <the_mart>
It uses surrogate pairs, but Java doesn’t have native support for them.

[06:19:00.0000] <hsivonen>
the_mart: java.nio.charset uses surrogate pairs natively

[06:19:01.0000] <hsivonen>
the_mart: my code is fully astral-aware

[06:19:02.0000] <the_mart>
Really?

[06:19:03.0000] <hsivonen>
the_mart: yes

[06:19:04.0000] <the_mart>
I’ll have to look at that.

[06:19:05.0000] <hsivonen>
the_mart: Sun even has done the right thing for java.io classes

[06:20:00.0000] <hsivonen>
the_mart: the implementation is hairy when you read one char at a time and the decoder needs to look ahead

[06:20:01.0000] <hsivonen>
the_mart: that's why I said I only covered the cases that my tokenizer needs

[06:20:02.0000] <the_mart>
Can it convert them to UTF-8 properly?

[06:20:03.0000] <hsivonen>
the_mart: yes. with error detection and everything

[06:20:04.0000] <the_mart>
Wow.

[06:21:00.0000] <the_mart>
I’m not really a Java person myself. :)

[06:21:01.0000] <hsivonen>
The JDK together with ICU4J is one of the best Unicode wrangling platforms around if you know what you are doing. (I do. :-)

[06:22:00.0000] <hsivonen>
far from perfect but other platforms suck more

[06:22:01.0000] <the_mart>
I prefer to program in C#.

[06:23:00.0000] <hsivonen>
/me prefers Sun shackles over Microsoft shackles

[06:23:01.0000] <the_mart>
:)

[06:23:02.0000] <zcorpan>
hsivonen: it's unclear whether two attributes with same local name and namespace is a fatal error or not

[06:23:03.0000] <the_mart>
Well it is standardised by ECMA.

[06:24:00.0000] <hsivonen>
zcorpan: interesting. I've never considered that case

[06:24:01.0000] <hsivonen>
the_mart: I don't value standards org labels that much

[06:25:00.0000] <zcorpan>
hsivonen: firefox/safari abort parsing. ie/opera don't. the spec says it's illegal but doesn't explicitly say that it's a namespace constraint

[06:26:00.0000] <Lachy>
has anyone made an issue page for longdesc on the wiki yet?  I can't find one mentioned anywhere

[06:26:01.0000] <hsivonen>
zcorpan: have you tested Xerces2-J?

[06:26:02.0000] <zcorpan>
hsivonen: no

[06:26:03.0000] <zcorpan>
http://simon.html5.org/test/xml/ns-malformed/001.xml

[06:27:00.0000] <the_mart>
Does IE actually support namespaces in XML though?

[06:27:01.0000] <hsivonen>
zcorpan: hmm. Ælfred2 does not detect an error

[06:28:00.0000] <zcorpan>
the_mart: yes

[06:30:00.0000] <hsivonen>
I guess I'm on the hook for fixing that if the XML folks decide it is a reportable error

[06:31:00.0000] <hsivonen>
that being Ælfred2 behavior

[06:31:01.0000] <annevk>
hmm, Opera fails too

[06:32:00.0000] <zcorpan>
i just wonder where i should report it. xml-names-issues isn't open anymore

[06:33:00.0000] <the_mart>
Isn’t it covered in section 6.3 of Namespaces in XML?

[06:35:00.0000] <zcorpan>
"The confusion comes from document conformace section that says regrading namespace-well-formedness that 'element and attribute names MUST match the production for QName and MUST satisfy the "Namespace Constraints". All other tokens in the document which are REQUIRED, for XML 1.0 well-formedness, to match the XML production for Name MUST match this specification's production for NCName'. Duplicate attributes issue is not explicitly mark

[06:35:01.0000] <zcorpan>
"namespace constraint" however."

[06:36:00.0000] <annevk>
I'd e-mail xml-editor

[06:36:01.0000] <zcorpan>
ok

[06:56:00.0000] <zcorpan>
"deprecated" is such a misunderstood term

[06:57:00.0000] <zcorpan>
people say that target="" is deprecated in html4 strict. but it really is forbidden in html4 strict but deprecated in html4 transitional

[06:59:00.0000] <annevk>
removing <img> is so not going to fly

[07:18:00.0000] <zcorpan>
http://forums.whatwg.org/viewtopic.php?t=69

[07:19:00.0000] <the_mart>
At least they don’t say that it’s “depreciated”. ;)

[07:25:00.0000] <annevk>
zcorpan, yeah, I noticed that error too, haven't reported it yet though...

[07:25:01.0000] <zcorpan>
i can forward the forum post to the list

[07:30:00.0000] <annevk>
sure

[08:06:00.0000] <zcorpan>
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/012022.html er, i must have screwed something up there

[08:07:00.0000] <zcorpan>
i positively had blank lines around the inner quote when i wrote it

[08:35:00.0000] <met_>
'Much of XHTML 2 works already in existing browsers' ( http://www.w3.org/TR/xhtml2/introduction.html#backCompat )

[08:36:00.0000] <annevk>
if you use client side XSLT... sure

[08:38:00.0000] <zcorpan>
much of FooML works already in existing browsers, too

[09:02:00.0000] <annevk>
Lachy, he means exceptions inside NSResolver

[09:03:00.0000] <annevk>
Lachy, which are raised while the UA executes it (I think, anyway)

[09:04:00.0000] <Lachy>
oh, I didn't realise.  I just assumed he meant the exceptions that are actually defined in the spec

[09:06:00.0000] <Lachy>
it should go to the caller anyway, at least in ecmascript, but it would really depend solely on how the programming language handles exceptions

[09:17:00.0000] <Philip`>
Could lookupNamespaceURI be called again after an exception has been thrown, before selectElement has returned? (Maybe some implementation with a non-interruptible selector system would just set an 'exception' flag when an exception is thrown, but then carry on as normal, before finishing and then rethrowing the exception out of selectElement, or something...)

[09:18:00.0000] <annevk>
yeah, it should probably say whether exceptions are ignored or re-raised

[09:19:00.0000] <Philip`>
/me wonders what would happen if you made lookupNamespaceURI call selectElement recursively

[09:19:01.0000] <Philip`>
(I guess JS implementations have a recursion limit, but does that apply to JS calling native code calling JS calling native code ...?)

[09:21:00.0000] <Philip`>
(I can't actually think of any existing cases where JS callbacks are run synchronously, but probably just because I'm unfamiliar with the area)

[09:32:00.0000] <Lachy>
any suggestions for wording to put in the spec?

[09:35:00.0000] <Philip`>
/me doesn't really know anything about it :-)

[09:42:00.0000] <Lachy>
I suppose it would work like a callback function, like in Array.forEach(callback)

[09:52:00.0000] <Lachy>
Does this sound ok? "If an exception is raised by the NSResolver while resolving namespaces, processing must be aborted and the exception passed back to the caller."

[10:01:00.0000] <Philip`>
That seems to make sense to me

[10:01:01.0000] <Lachy>
I haven't checked it in yet.  I sent it to the list to see if someone has any better suggestions, since the issue is not entirely clear to me either

[10:02:00.0000] <Philip`>
though the word "passed" doesn't seem to fit perfectly for exceptions, since that makes them sound more like return values, but I can't think of anything better

[10:02:01.0000] <Lachy>
perhaps "propogated" instead

[10:02:02.0000] <Philip`>
(Also, I guess it should say "NSResolver (or ECMAScript Function)" like I vaguely remember it saying elsewhere)

[10:02:03.0000] <Lachy>
propagated, even

[10:03:00.0000] <Philip`>
That sounds reasonable

[10:03:01.0000] <Lachy>
not necessary, since I've already defined that the ECMAScript Function is just a special language binding for the NSResolver

[10:04:00.0000] <Philip`>
Ah, okay

[11:38:00.0000] <Lachy_>
/me wonders why the video codec thread is continuing. I thought the solution was already explained.

[11:40:00.0000] <Lachy>
As long as third parties are able to provide browser plugins and codecs that work with <video>, UAs don't need native support for every format built in.  Firefox, for example, shoud be able to invoke QuickTime for MP4 content, as long as QuickTime provides an appropriate API for FF to work with.

[11:41:00.0000] <Lachy>
or even VLC

[11:49:00.0000] <the_mart>
Yeah, and it’s a bit harsh how some people keep having a go at Apple over it.

[11:55:00.0000] <tndH>
I suspect some people will still be arguing after the patents have expired.

[13:05:00.0000] <maikmerten>
Lachy, well, the problem is: VLC isn't really legal in many countries and QuickTime isn't installed on many system. I do think it may make sense if browsers try to invoke external media frameworks if they can't handle content themselves, though.

[13:05:01.0000] <maikmerten>
however, they still should ship with at least one set of codec content providers can rely on

[13:06:00.0000] <maikmerten>
in worst case that'd mean the market would be split between WMV, MP4 and Ogg.

[13:07:00.0000] <maikmerten>
but that means you "only" need to encode 3 versions to server like 99% of potential customers ;)

[13:07:01.0000] <Lachy>
They don't have to ship with VLC in the browser.

[13:08:00.0000] <maikmerten>
right

[13:08:01.0000] <maikmerten>
well, anyway, at least on Windows the more generic choice would be DirectShow

[13:08:02.0000] <maikmerten>
on Mac it would be QuickTime

[13:08:03.0000] <maikmerten>
and on Linux perhaps GStreamer

[13:09:00.0000] <Lachy>
any third party should be able to write and distribute a plugin that will work with the browser, and if VLC does that from their site, no-one can stop any user from downloading it

[13:09:01.0000] <maikmerten>
that should suffice, combined with one natively supported codec

[13:10:00.0000] <maikmerten>
well, as a matter of fact VLC does have a browser plugin already

[13:10:01.0000] <Lachy>
anyway, I should get some sleep. good night

[13:10:02.0000] <maikmerten>
night

[14:22:00.0000] <Hixie>
Jero?

[14:22:01.0000] <Jero>
yes?

[14:22:02.0000] <Hixie>
so that thing you were asking about

[14:22:03.0000] <Jero>
the "...but no start tag token has ever been emitted by this instance of the tokeniser (fragment case)..." thing?

[14:23:00.0000] <Hixie>
yeah

[14:23:01.0000] <Hixie>
let me find it, hold on

[14:23:02.0000] <Jero>
sure

[14:23:03.0000] <Hixie>
ah, i see

[14:23:04.0000] <Hixie>
it doesn't mean "is the stack empty", because the stack is basically never empty (at least not in the fragment case)

[14:24:00.0000] <Hixie>
nor does it mean "is there only one thing in the stack"

[14:24:01.0000] <Hixie>
e.g. it wouldn't fire for the second "</" in <html><head></head></head></html>

[14:24:02.0000] <Hixie>
it literally means that no start tag token has ever been emitted

[14:25:00.0000] <Hixie>
e.g. because you're doing the innerHTML of a <style> element

[14:25:01.0000] <Jero>
oh i see, so in the fragment case, you really need to keep track of the amount processed start tag?

[14:34:00.0000] <Hixie>
Jero: somehow or other, yeah

[14:34:01.0000] <Jero>
ok, thanks for your response

[16:27:00.0000] <Hixie>
/me wonders if someone is going to point out to Sebastian

[16:27:01.0000] <Hixie>
that XHTML 1 and XHTML 2 have the same problem

[16:27:02.0000] <Hixie>
and that in fact XHTML2 and HTML have the same problem

[16:28:00.0000] <Hixie>
and that XHTML5 and HTML5 are good matches for precisely the reason he gave...

[16:30:00.0000] <nickshanks>
/me winders what ian is going on about

[16:30:01.0000] <nickshanks>
*wonders even

[16:30:02.0000] <Philip`>
http://lists.w3.org/Archives/Public/public-html/2007Jun/0866.html

[16:31:00.0000] <Hixie>
yeah

[16:36:00.0000] <nickshanks>
yeah, he seems to have slipped up there

[16:36:01.0000] <nickshanks>
but his surname makes up for that

[16:37:00.0000] <zcorpan>
i also don't see how he can know that using the name xhtml5 will result in more confusion than a different name (that he didn't propose)

[16:38:00.0000] <zcorpan>
e.g., if we call the xml serialization of html5 "bob", will there be less confusion than if we called it "xhtml5"?

[16:39:00.0000] <nickshanks>
Would IE 8's implementation be called Microsoft Bob the?

[16:39:01.0000] <nickshanks>
then

[16:42:00.0000] <zcorpan>
/me will create an xml serialization of html3.2. and name it xhtml3.2

[16:47:00.0000] <nickshanks>
HTML 3.0 had some nice things in it

[16:47:01.0000] <nickshanks>
so don't neglact that one too :)

[16:47:02.0000] <Hixie>
any other than maths and <credit> that we haven't taken yet?

[16:47:03.0000] <zcorpan>
<note>

[16:47:04.0000] <Hixie>
<aside>

[16:48:00.0000] <nickshanks>
i still want an <image> element that takes fallback content

[16:50:00.0000] <nickshanks>
Hixie: do you recall how many webpages used <image> as an empty element (i.e. they meant <img>)?

[16:50:01.0000] <zcorpan>
nickshanks: how would you check that?

[16:51:00.0000] <nickshanks>
by looking for </image>

[16:51:01.0000] <nickshanks>
oh, never mind, the google web survey only counted opening tags

[16:53:00.0000] <Hixie>
use <object>

[16:53:01.0000] <Hixie>
we can't change <image> handling.

[16:55:00.0000] <othermaciej>
<image> is one of those things that makes you doubt reading people's reading comprehension

[16:57:00.0000] <zcorpan>
</p style=border:solid> -- opera and safari render a border, ie and firefox don't

[16:58:00.0000] <nickshanks>
hahaha


2007-06-27
[17:00:00.0000] <nickshanks>
zcorpan: i logged that against safari as 14423

[17:00:01.0000] <zcorpan>
following ie/firefox would be to just say "act as if a p start tag with no attributes has been seen then reprocess the current token" or something

[17:04:00.0000] <zcorpan>
nickshanks: not closing tags in general (it's just </p> and </br> that are magic... except in ie...) and not style attributes specifically

[17:05:00.0000] <nickshanks>
oh, i misunderstood you then

[17:14:00.0000] <Hixie>
ok </p> and </br> magic is now in the spec

[17:14:01.0000] <Hixie>
annevk: would be cool if the web-apps-tracker had a way of showing the changelist going further back than the last N changes

[17:16:00.0000] <Hixie>
/me starts the daunting task of backporting all the changes to the parser spec into his year-old parser

[17:24:00.0000] <Hixie>
annevk: also cool would be a "next" link next to "I've read the changes!", so that you can go through the diffs one at a time

[17:25:00.0000] <othermaciej>
is annevk actually here?

[17:25:01.0000] <Hixie>
no idea but i'm sure he'll see the comments when he comes back online later if no

[17:25:02.0000] <Hixie>
t

[17:26:00.0000] <othermaciej>
I'd want to talk to him if he was, is all

[17:26:01.0000] <Hixie>
ah

[17:27:00.0000] <Hixie>
wow, still nobody has pointed out sebastian's faux pas

[17:28:00.0000] <othermaciej>
you mean that the more obvious solution would be to rename XHTML 2?

[17:29:00.0000] <Hixie>
yeah (http://krijnhoetmer.nl/irc-logs/whatwg/20070627#l-8)

[17:30:00.0000] <Hixie>
i wish i understood what the www-tag were talking about

[17:30:01.0000] <othermaciej>
in general? or is there some specific issue at hand?

[17:31:00.0000] <Hixie>
most of the discussion in www-tag is way over my head

[17:31:01.0000] <Hixie>
they're arguing about the meaning of "resource" as far as i can tell

[17:36:00.0000] <Hixie>
hahaha, his mail got +1ed!

[17:36:01.0000] <Hixie>
given my e-mail earlier today that's especially funny

[17:40:00.0000] <nickshanks>
i know what resource means

[17:41:00.0000] <nickshanks>
it's a data block referenced by a ResourceHandle  :)

[18:20:00.0000] <zcorpan>
Hixie: please make stray </p> and </br> parse errors

[18:22:00.0000] <zcorpan>
s/<\/p> and //

[18:23:00.0000] <Hixie>
valid request!

[18:24:00.0000] <Hixie>
done

[18:30:00.0000] <zcorpan>
Hixie: stray </p> were already parse errors, apparently: "If the current node is not a p element, then this is a parse error."

[18:30:01.0000] <Hixie>
d'oh

[18:31:00.0000] <Hixie>
fixed

[18:34:00.0000] <zcorpan>
nn

[18:41:00.0000] <Philip`>
Lachy: In Selectors: s/consise/concise/

[18:49:00.0000] <mpt>
I don't care about the name of HTML 5's XML serialization, I want to know what HTML 5's codename is going to be

[18:49:01.0000] <mpt>
HTML 3.2 was Wilbur

[18:49:02.0000] <mpt>
HTML 4.0 was Cougar

[18:49:03.0000] <mpt>
HTML 5 is ...

[18:50:00.0000] <Hixie>
Web Apps 1.0 is HTML 5 :-)

[18:50:01.0000] <Hixie>
HTML5 _was_ the codename :-)

[18:50:02.0000] <mpt>
oh but that's so boring

[18:51:00.0000] <Hixie>
hey, i'm just telling it how it is

[19:09:00.0000] <Lachy>
Philip`: fixed.

[19:11:00.0000] <Hixie>
/me gets to r886

[19:11:01.0000] <Hixie>
well crap, now i have to do work

[23:34:00.0000] <Hixie>
oh hey, people did eventually point out to sebastian that he was made a mistake

[23:34:01.0000] <Hixie>
/me looks forward to the reply

[23:35:00.0000] <Hixie>
this whole naming this is such a joke

[23:35:01.0000] <Hixie>
i don't understand why we can't just share the name

[23:35:02.0000] <Hixie>
maybe we should call our XML serialisation "XHTML1 5"

[23:35:03.0000] <Hixie>
which would get shorted to XHTML 15

[00:07:00.0000] <Lachy>
Sebastian responded to me off list and accused me of not addressing his argument. :-/

[00:25:00.0000] <Hixie>
what was his argument?

[00:25:01.0000] <Hixie>
You can make the exact same e-mail with s/2/5/ and vice versa

[00:25:02.0000] <Hixie>
or rather

[00:26:00.0000] <Hixie>
s/2/5/ and s/5/1/

[00:26:01.0000] <othermaciej>
I think he would claim that 2 is the valid authoritative continuation of xhtml 1, and 5 is a fork

[00:27:00.0000] <Lachy>
Hixie: this one http://www.w3.org/mid/4681C56C.8020501⊙lia

[00:27:01.0000] <othermaciej>
i.e. that organizational continuity trumps language-level compatibility

[00:28:00.0000] <othermaciej>
I don't think sharing the name "XHTML" is a problem and the fact that it is even being debated is annoying

[00:28:01.0000] <Hixie>
me neither

[00:28:02.0000] <Hixie>
and i agree

[00:28:03.0000] <Hixie>
i really don't understand the problem

[00:28:04.0000] <Lachy>
there isn't a problem, which is why I said that the debate needs to stop

[00:29:00.0000] <Hixie>
the thing that nobody has brought up is that XHTML5 is one of _three_ new names in the spec

[00:29:01.0000] <Hixie>
HTML5, XHTML5, and DOM5 HTML

[00:29:02.0000] <Hixie>
and having one of those have a different number than the others would be aethestically very displeasing

[00:29:03.0000] <Hixie>
imho

[00:31:00.0000] <Lachy>
let's just drop the number, call it HTML, XHTML and DOM

[00:31:01.0000] <Hixie>
that'd go down well with the versionists

[00:32:00.0000] <othermaciej>
DOM5 HTML is kind of odd, since there is otherwise no such thing as DOM5

[00:33:00.0000] <othermaciej>
and with the HTML DOM in the spec, it's not really tied to a specific DOM Core level any more, in any case

[00:33:01.0000] <othermaciej>
but that's a whole other can of worms

[00:33:02.0000] <Hixie>
DOM HTML 5

[00:34:00.0000] <Lachy>
or DHTML5

[00:34:01.0000] <Lachy>
:-)

[00:34:02.0000] <othermaciej>
HTML5 DOM

[00:34:03.0000] <othermaciej>
(SVG spec refers to the "SVG DOM")

[00:35:00.0000] <othermaciej>
I'm not sure if any other w3c languages have a DOM

[00:38:00.0000] <othermaciej>
XForms appears to have a bunch of events, and only has a DOM interface for the <model> element (wow, it must be brutally painful to use with scripting)

[00:38:01.0000] <othermaciej>
MathML calls it the "MathML DOM"

[00:51:00.0000] <annevk>
someone should e-mail the Sebastian e-mail again and just change XHTML5 to XHTML 2.0 and XHTML 2.0 to XHTML5 :)

[00:52:00.0000] <hsivonen>
aargh. entity tokenization is subtle. I change something and a bunch of test cases fail :-(

[00:54:00.0000] <annevk>
at least the test harness is no longer broken :)

[00:55:00.0000] <othermaciej>
hey annevk 

[00:55:01.0000] <annevk>
morning

[00:55:02.0000] <annevk>
I see you wanted to ask me something...

[00:55:03.0000] <hsivonen>
annevk: yeah. there are some new tests that are wrong, too. fixing those now

[01:07:00.0000] <othermaciej>
annevk: just wanted to talk about the design principles document, but I don't remember if I had anything specific - I'll try to do a proofreading pass on it to improve the wording

[01:07:01.0000] <annevk>
just edit and commit I'd say

[01:46:00.0000] <annevk>
the </p> and </br> fix in HTML5 was no good btw

[01:47:00.0000] <annevk>
it's more complicated than that

[01:47:01.0000] <annevk>
Hixie, you need to let </br> and </p> pass to trough the <head> element phases and such as well

[01:48:00.0000] <annevk>
to make <!doctype html></br> work

[01:53:00.0000] <Hixie>
send mail?

[01:54:00.0000] <Hixie>
nn

[01:54:01.0000] <annevk>
done

[01:54:02.0000] <annevk>
g'night

[01:57:00.0000] <zcorpan>
"behave similar to the browsers we try to imitate in English." -- in English?

[01:59:00.0000] <annevk>
the parsing spec is in English, no?

[02:00:00.0000] <zcorpan>
oh. yes. it sounded like you tried to imitate in english

[02:04:00.0000] <annevk>
landed support for my version of the spec in html5lib

[03:13:00.0000] <annevk>
Hixie, we don't have <ruby>

[03:35:00.0000] <zcorpan>
hmm, wonder what i should write test cases for today. content-type sniffing perhaps?

[03:36:00.0000] <annevk>
<embed>, <object>, etc.?

[03:36:01.0000] <zcorpan>
sure

[03:36:02.0000] <othermaciej>
I'd really like to see someone start organizing test cases into a test suite

[03:37:00.0000] <othermaciej>
at least for more solid areas of the spec

[03:37:01.0000] <zcorpan>
i might do that later on

[03:37:02.0000] <annevk>
it would be nice if all <canvas> tests were somehow merged

[03:38:00.0000] <annevk>
and checked for conformance

[03:40:00.0000] <othermaciej>
yeah

[03:41:00.0000] <othermaciej>
that is one area that is ripe for being turned into a test suite

[03:41:01.0000] <othermaciej>
parser tests might be another

[03:41:02.0000] <annevk>
we have loads of parser tests

[03:41:03.0000] <annevk>
and I believe someone wrote a JS framework for them

[03:41:04.0000] <othermaciej>
so someone needs to review and slap them into dev.w3.org

[03:42:00.0000] <zcorpan>
how should we deal with automated testing in general?

[03:43:00.0000] <othermaciej>
there's kind of a tradeoff here

[03:43:01.0000] <othermaciej>
if you build a test automation framework, that might make the tests harder to integrate into existing test automation frameworks

[03:43:02.0000] <annevk>
we have this boilerplate for automated tests: "try{top.opener.rr(passed);}catch(e){}"

[03:43:03.0000] <annevk>
that should be quite trivial to integrate in any framework

[03:43:04.0000] <othermaciej>
for instance the WebKit regression test suite works best on just raw html files

[03:44:00.0000] <annevk>
that's for tests that have some JS in them

[03:44:01.0000] <zcorpan>
or where the result can be determinated with js

[03:44:02.0000] <annevk>
right

[03:45:00.0000] <othermaciej>
I guess top.opener would be nil in our regression test system and so harmless

[03:45:01.0000] <annevk>
it means you either run them in an iframe or some popup window

[03:45:02.0000] <zcorpan>
i could use both visual indicator and try{top.opener.rr(result);}catch(e){} where possible

[03:45:03.0000] <annevk>
yeah, most XMLHttpRequest tests on tc.labs.opera.com work that way

[03:46:00.0000] <zcorpan>
ok. good

[03:46:01.0000] <othermaciej>
we have a nice framework for test assertions that can be expressed in JS in WebKit

[03:46:02.0000] <annevk>
there's also a small thingie that lets you run the tests in serie

[03:46:03.0000] <othermaciej>
I made a sorta-clone of it for the Window spec

[03:46:04.0000] <annevk>
and report the results

[03:47:00.0000] <othermaciej>
see here for a live example: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WindowTestSuite/publish/html/ecmascript/browsing-contexts/Window-document.html

[03:47:01.0000] <othermaciej>
probably only really good for API tests though

[03:51:00.0000] <zcorpan>
hmm... perhaps i should use the same technique as hsivonen proposed for document conformance indication -- a file that lists all tests are noninteractive

[03:52:00.0000] <zcorpan>
or use different folders

[03:53:00.0000] <zcorpan>
or in the file name -- 001-noninteractive.htm

[03:54:00.0000] <annevk>
js-framework.txt

[03:54:01.0000] <annevk>
although you don't really need that

[03:54:02.0000] <annevk>
if you simply stick with the boilerplate mentioned above a simple crawling script can take care of that

[03:55:00.0000] <zcorpan>
oh, right

[05:01:00.0000] <Philip`>
My approach to the canvas tests is to write them all in YAML with some Python that writes HTML (and PNG), so I'd guess it should be straightforward for that to output different HTML for a different test framework

[05:25:00.0000] <zcorpan>
made http://simon.html5.org/test/html/parsing/stray-end-tags/with-attributes/ non-interactive

[05:51:00.0000] <annevk>
we need a http://www.google.com/search?q=site%3Alists.whatwg.org+{s} bookmarklet :D

[06:02:00.0000] <mw22>
I think you more need to just answer the question

[06:03:00.0000] <annevk>
if you have time to do that, great

[06:04:00.0000] <annevk>
having people do some research into previous discussions isn't that bad I think

[06:06:00.0000] <mw22>
well, if there is no time to anser question, just tell that then

[06:08:00.0000] <annevk>
this seems more helpful

[06:10:00.0000] <mw22>
no, it's not

[06:11:00.0000] <annevk>
that's just your opinion

[06:11:01.0000] <mw22>
no, it's not

[06:11:02.0000] <annevk>
ok

[06:12:00.0000] <hsivonen>
mw22: my reply may have been impolitely terse but at least it points to where you can find the answer

[06:14:00.0000] <mw22>
hsivonen, yeah, I also think it's impolite, it would be somewhat friendlier if you at least added one line ('maybe this is useful?') to it

[06:15:00.0000] <hsivonen>
will do next time

[06:16:00.0000] <mw22>
ok, thanks

[06:16:01.0000] <hsivonen>
yay, Minefield now supports em-sized <svg> elements

[06:40:00.0000] <annevk>
mw22, you see, the person found it helpful ;)

[06:40:01.0000] <mw22>
annevk, I don't have the reply yet, gmail sucks ;)

[06:41:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-html/2007Jun/0900.html

[06:47:00.0000] <mw22>
ah, ok, so now someone should probably reply to him that there is not time to answer his question, but it was already answered and he should look for it himself, or something along that line

[06:48:00.0000] <mw22>
I still don't have that mail in my mail box

[06:48:01.0000] <mw22>
gmail is really slow

[06:52:00.0000] <mw22>
oops, no, it's my fault

[06:58:00.0000] <Lachy>
someone reply and say that it is not the purpose of the differences document to provide justification for the changes, just to reflect the current state of the spec and describe what they are

[06:58:01.0000] <annevk>
the difference doc provides some rationale

[06:59:00.0000] <Lachy>
yeah, but not the detailed rationale some people are asking for, like the people wanting it to explain why accessibility features have been dropped

[06:59:01.0000] <annevk>
yeah whatever

[07:00:00.0000] <annevk>
I'll leave that up to Danc I think

[07:00:01.0000] <mw22>
http://tools.ietf.org/html/draft-ietf-run-netiquette-guide-00

[07:00:02.0000] <mw22>
"Be brief without being overly terse.  When replying to a message, include enough original material to be understood."

[07:01:00.0000] <annevk>
see above

[07:02:00.0000] <virtuelv>
mw22: see http://tools.ietf.org/html/rfc1855 instead

[07:03:00.0000] <mw22>
virtuelv, thanks

[08:28:00.0000] <krijnh>
Oi, anything interesting happened lately?

[09:44:00.0000] <gsnedders>
hmmm… I've been asking around about people's thoughts on recommending a codec, and the consensus is there should be either none, or multiple recommendations, all of which should be openly documented

[10:12:00.0000] <zcorpan>
a working draft is not a "spec"?

[10:14:00.0000] <annevk>
I think it is

[10:14:01.0000] <annevk>
well, depends on the type of working draft... some are specs, others are not

[10:14:02.0000] <zcorpan>
e.g. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8

[10:15:00.0000] <zcorpan>
i referred to that as "the spec", and got a reply that it wasn't a spec. it was a working draft

[10:16:00.0000] <annevk>
heh

[10:17:00.0000] <annevk>
at some point it might become a "W3C Recommendation"

[10:18:00.0000] <hsivonen>
annevk: do I understand correctly that html5lib unifies phases and insertion modes?

[10:21:00.0000] <annevk>
yes

[10:21:01.0000] <annevk>
we need that to correctly deal with EOF

[10:21:02.0000] <hsivonen>
annevk: is there a reason why the spec doesn't?

[10:22:00.0000] <annevk>
the spec doesn't deal correctly with EOF yet

[10:22:01.0000] <annevk>
I suppose Hixie will fold them in due course too

[10:22:02.0000] <hsivonen>
oh great

[10:22:03.0000] <hsivonen>
tracking that spec refactoring will be a mess

[10:22:04.0000] <annevk>
this is about corner cases such as "<!doctype html>" not giving you "<!DOCTYPE html><html><head></head><body></body>"

[10:23:00.0000] <hsivonen>
annevk: is your deviation from the spec written down in English somewhere?

[10:23:01.0000] <annevk>
Hixie said it would be a fairly trivial change

[10:24:00.0000] <annevk>
hsivonen, it's quite simple, put the three tokens that are handled the same for each insertion mode in HTML 5 in each insertion mode and then drop the concept of insertion modes

[10:25:00.0000] <annevk>
hsivonen, then modifiy EOF in each phase appropriately

[10:25:01.0000] <hsivonen>
annevk: ok. thanks

[10:28:00.0000] <annevk>
I was just thinking that maybe your Java parser might be fast enough for surveys

[10:31:00.0000] <hsivonen>
annevk: I've been thinking about that, too.

[12:11:00.0000] <duryodhan>
hey is there an upper limit to the height for <canvax> drawWindow method ?

[13:18:00.0000] <Jero>
What was the last spec revision html5lib implemented?

[13:20:00.0000] <annevk>
I implemented </br> and </p>

[13:21:00.0000] <Jero>
oh cool, that basically means html5lib is completely up to date, right?

[13:22:00.0000] <annevk>
I guess

[13:22:01.0000] <annevk>
if you find bugs, let me know

[13:24:00.0000] <Jero>
i will, but i just wanted to be sure i'm not testing the results of my parser against the results of html5lib if it were a couple of revisions behind

[13:25:00.0000] <Jero>
though i think i should reorganize my parser a bit

[13:25:01.0000] <Jero>
one big file of almost 5000 lines isn't exactly optimal

[13:25:02.0000] <annevk>
we're a little bit ahead of the spec fwiw

[13:25:03.0000] <Jero>
sweet

[13:25:04.0000] <annevk>
EOF handling and what I posted regarding </br> and </p> on the list

[13:26:00.0000] <Jero>
cool

[13:51:00.0000] <hsivonen>
Hixie: how does one determine if <datagrid> is being used as a tree widget or whether it is being used as a grid widget?

[14:01:00.0000] <Jero>
annevk, <t?> makes the script throw an internal error

[14:01:01.0000] <Jero>
and by script i mean html5lib of course

[14:02:00.0000] <annevk>
wfm

[14:02:01.0000] <annevk>
using the latest SVN version?

[14:03:00.0000] <Jero>
no, i'm using hasather.net atm

[14:03:01.0000] <annevk>
that might not be up to date

[14:04:00.0000] <Jero>
yeah, i guess that's the case then

[14:05:00.0000] <Hixie>
hsivonen: i don't understand the question (datagrid)

[14:07:00.0000] <hsivonen>
Hixie: platform widget sets have tree widgets (disclosure triangles or equivalent on the left) and grid widgets (typically no disclosure triagles, column headings available)

[14:07:01.0000] <hsivonen>
Hixie: how should a UA decide which widget to use?

[14:07:02.0000] <hsivonen>
Hixie: should the UA report the datagrid to AT as a tree or as a grid?

[14:08:00.0000] <hasather>
Jero: I upgraded html5lib just minutes ago

[14:08:01.0000] <annevk>
Jero, if you checkout the CVS version you can cd into the python directorary and run something like 'python parse.py "<t?>"' and get something out of it

[14:08:02.0000] <hsivonen>
/me is creating a table that shows mappings between WAI roles and HTML5 features

[14:08:03.0000] <Hixie>
hsivonen: the <datagrid> element is both, you can have it in a mode with headers amd discolsure triangles

[14:08:04.0000] <annevk>
hasather, why does http://hasather.net/html5/parsetree/parsetree?source=%3Ct%3E throw an error though?

[14:08:05.0000] <Jero>
annevk, that's good to know, not an expert at Python yet, thanks!

[14:08:06.0000] <annevk>
hasather, does it have strict handling?

[14:09:00.0000] <hsivonen>
Hixie: so do you report it to AT as a tree or as a grid?

[14:09:01.0000] <hsivonen>
Hixie: is there a way to tell?

[14:09:02.0000] <annevk>
hasather, everything throws errors, it seems like something is no longer correct

[14:09:03.0000] <hasather>
annevk: yea, I look into it

[14:10:00.0000] <annevk>
/me wonders if there were any architecture changes

[14:10:01.0000] <Hixie>
hsivonen: report it as a tree, i guess, though it might all be at the same level

[14:11:00.0000] <hsivonen>
Hixie: mmkay

[14:11:01.0000] <hsivonen>
Hixie: I expect this spec detail will get comments down the road

[14:11:02.0000] <annevk>
<datagrid> is quite hard to get through as currently specced :(

[14:13:00.0000] <Hixie>
hsivonen: as far as i can tell, the <datagrid> widget maps directly to the widget in iTunes and to similar widgets in pretty much every modern mail client

[14:13:01.0000] <Hixie>
hell even _pine_ uses this kind of widget

[14:15:00.0000] <hsivonen>
hmm. I see disclosure triangles in iTunes only in the Podcast view

[14:15:01.0000] <hsivonen>
and in that view they aren't the leftmost column...

[14:16:00.0000] <hsivonen>
Hixie: how does JAWS read that widget to you?

[14:16:01.0000] <hsivonen>
/me turns on VoiceOver

[14:18:00.0000] <hsivonen>
when VoiceOver reads a cell that is on a row that has an open disclosure triagle, it says "expanded"

[14:19:00.0000] <hsivonen>
it seems that VoiceOver groks the concept of cell and the expanded status of rows at the same time

[14:19:01.0000] <Hixie>
dunno, haven't tried using JAWS there yet

[14:19:02.0000] <annevk>
Hixie, are you creating a new code.google.com/ page this week or doing different surveys?

[14:20:00.0000] <hasather>
annevk: Jero: I'm back to the old version for now. I don't really have time to look into it now, but I'll update it as quickly as possible

[14:21:00.0000] <Jero>
no problem, thanks!

[14:22:00.0000] <Jero>
... @ PHP's built-in DOM implementation

[14:22:01.0000] <Hixie>
annevk: ?

[14:22:02.0000] <Jero>
$dom->createElement('p-') causes it to throw an error

[14:22:03.0000] <annevk>
Hixie, specifically, publishing a new version of the 2005-12 stats

[14:26:00.0000] <Hixie>
annevk: i might do, if i find something worth publishing. let me know if you have any ideas on what i should study.

[14:27:00.0000] <Hixie>
wow, my e-mail had absolutely no effect on public-html

[14:27:01.0000] <Hixie>
people are still just shouting at each other over style="", over role="", over <object>...

[14:27:02.0000] <annevk>
in addition you got a lengthy e-mail back :)

[14:28:00.0000] <Hixie>
oh good

[14:28:01.0000] <annevk>
Hixie, I'd be very interested how often the adoption agency algorithm is hit

[14:28:02.0000] <Hixie>
haven't got to that yet

[14:28:03.0000] <Hixie>
^_^

[14:29:00.0000] <Hixie>
i could report frequency of certain errors i guess

[14:29:01.0000] <annevk>
As in, how many times is an element duplicated in the average case

[14:29:02.0000] <Hixie>
my parser skips straight past the entity parsing and the input stream tweaking (e.g. getting rid of U+0000)

[14:29:03.0000] <Hixie>
hm, might be able to do that

[14:30:00.0000] <Hixie>
mail the list?

[14:30:01.0000] <Hixie>
or me

[14:30:02.0000] <Hixie>
best jut e-mail me on that

[14:30:03.0000] <annevk>
And maybe investigate if we can adopt the Safari algorithm that produces significantly less elements

[14:30:04.0000] <Hixie>
ian⊙hc

[14:30:05.0000] <Hixie>
i thought that's what the spec was

[14:30:06.0000] <Hixie>
what's the difference?

[14:31:00.0000] <Hixie>
/me wonders why sebastian doesn't mind XHTML 1.5 as much as XHTML5

[14:31:01.0000] <othermaciej>
I guess because it gives the impression that XHTML2 is the future

[14:31:02.0000] <othermaciej>
(and always will be)

[14:32:00.0000] <zcorpan>
1.5 doesn't have the useful property of being able to say (x)html5

[14:33:00.0000] <zcorpan>
anyway

[14:33:01.0000] <zcorpan>
/me will stay away from naming debates

[14:34:00.0000] <annevk>
for <p><b><p>...<p>...<p>... the spec does <p><b></b><p><b>....</b><p> and Safari does <p><b>..</b><p><b><p>...</p> ...</b> aiui

[14:35:00.0000] <annevk>
dhyatt said that it's less expensive than the current algorithm but they encountered one issue with it so far

[14:35:01.0000] <hsivonen>
Hixie: answer to http://lists.whatwg.org/pipermail/implementors-whatwg.org/2007-June/000108.html would be good to know if you happen to discover it as a side effect of your research

[14:36:00.0000] <hsivonen>
I'm similarly interested in attribute value and comments lengths

[14:38:00.0000] <hsivonen>
are XForms alerts modal?

[14:41:00.0000] <Hixie>
hsivonen: yeah that's on my list of things to look at

[14:42:00.0000] <Hixie>
annevk: oh you mean reopen the formatting elements for block elements as well as inline elements?

[14:42:01.0000] <hsivonen>
Hixie: great

[14:44:00.0000] <annevk>
Hixie, maybe, dunno

[14:46:00.0000] <annevk>
they reopen the inline accross the next set of elements instead of reopening it in each one of them

[14:46:01.0000] <annevk>
according to dhyatt

[14:59:00.0000] <Hixie>
annevk: right, so reopening it for blocks instead of inlines

[14:59:01.0000] <Hixie>
or as well as

[14:59:02.0000] <Hixie>
as i said in e-mail, not really sure how to quantify that

[15:01:00.0000] <hsivonen>
a WAI spinbutton offers "discreet" choices...

[15:02:00.0000] <hsivonen>
is input type='number' with step, min and max supposed to be rendered as a "spinbutton"?

[15:11:00.0000] <Hixie>
it could be, sure

[15:12:00.0000] <Hixie>
i'm amused that WAI is exposing platform-specific and presentation-derived widget concepts, instead of exposing underlying concepts and allowing ATs to optimise for their users

[15:56:00.0000] <hsivonen>
Hixie: what's the deal with "limited quirks" when everyone calls it "almost standards"?

[16:16:00.0000] <Hixie>
hsivonen: it's no longer "almost standards". quirks, limited quirks, and no quirks are all standards now.

[16:18:00.0000] <Hixie>
lordy, poor lachy

[16:18:01.0000] <zcorpan>
/me hopes that limited and no quirks still can be merged... not sure if it'll fly

[16:19:00.0000] <Hixie>
the only difference is the inline box model

[16:19:01.0000] <Hixie>
and that can't be merged

[16:19:02.0000] <Hixie>
it's why the mode exists

[16:20:00.0000] <zcorpan>
the mode exists because mozilla wanted to comply with the css spec, and the spec was incompatible with the real world

[16:21:00.0000] <Hixie>
it must be pointed out that the spec's inline box model is far superior to the legacy rendering mode

[16:21:01.0000] <zcorpan>
but perhaps there is enough content on the web using standards mode and relying on the standards inline model (despite ie not supporting it) that it can't be merged after all

[16:21:02.0000] <zcorpan>
oh sure

[16:21:03.0000] <Hixie>
at least typographically

[16:21:04.0000] <zcorpan>
but having two modes suck

[16:21:05.0000] <Hixie>
sure

[16:21:06.0000] <Hixie>
having four is even worse

[16:21:07.0000] <Hixie>
we have four right now

[16:21:08.0000] <zcorpan>
yeah

[16:21:09.0000] <Hixie>
at least they're not too far apart

[16:22:00.0000] <Hixie>
microsoft want to introduce even more, with much bigger differences

[16:23:00.0000] <zcorpan>
yeah well. still, 90% of the web or so is in quirks mode

[16:24:00.0000] <Hixie>
i plan to discover exactly how much this week

[16:25:00.0000] <Hixie>
since the spec now requires me to implement doctype parsing :-P

[16:25:01.0000] <zcorpan>
:)

[16:25:02.0000] <zcorpan>
i would also like to know the ratio between almost/full

[16:26:00.0000] <Hixie>
well the %age of xml-mode is about 0.0014%

[16:26:01.0000] <Hixie>
last i checked

[16:26:02.0000] <zcorpan>
(which i'd expect to be 9:1)

[16:26:03.0000] <zcorpan>
yeah

[16:26:04.0000] <Hixie>
so it's bound to be higher than that for the other one

[16:28:00.0000] <Hixie>
bbl


2007-06-28
[17:17:00.0000] <Philip`>
Ooh, WebKit's globalCompositeOperation = 'highlight' is much easier than I thought it might be

[17:18:00.0000] <Philip`>
(since it's a deprecated part of Cocoa (or whatever it is), and acts as a synonym for 'source-over')

[17:35:00.0000] <zcorpan>
hmm, wonder what conformance requirements there should be for placeholder="" (for UAs)

[17:36:00.0000] <Hixie>
wish i knew wtf the guy in the entity thread actually wanted

[17:36:01.0000] <zcorpan>
e.g. should UAs be allowed to present the placeholder text to the user in some way even when the value is not empty?

[17:36:02.0000] <zcorpan>
wonder if that could make sense in some media

[17:37:00.0000] <Hixie>
maybe

[17:37:01.0000] <Hixie>
i don't think we should disallow it

[17:37:02.0000] <zcorpan>
indeed

[17:39:00.0000] <zcorpan>
http://simon.html5.org/temp/search-control.htm

[17:39:01.0000] <zcorpan>
that was originally a much bigger spec

[17:39:02.0000] <zcorpan>
heh

[17:40:00.0000] <Hixie>
i don't think we should have type=search, personally

[17:40:01.0000] <Hixie>
it's a text field

[17:40:02.0000] <Hixie>
its searchingness is orthogonal

[17:40:03.0000] <Hixie>
e.g. you could have a numeric search field

[17:41:00.0000] <Hixie>
agreed on the placeholder thing though

[17:42:00.0000] <zcorpan>
hmm... i think search fields are almost always free-text

[17:42:01.0000] <Hixie>
sure

[17:43:00.0000] <Hixie>
but it's not a type

[17:44:00.0000] <zcorpan>
if you want to skip to a search field, you'd want to skip directly to that control so you can start typing. an attribute on <input>? <input search>?

[17:44:01.0000] <Hixie>
or class=search

[17:44:02.0000] <Hixie>
which is widely used

[17:45:00.0000] <webben_>
zcorpan: isn't that reinventing WebKit's type="search"?

[17:45:01.0000] <webben_>
possibly <search> various stuff goes here </search> would be better

[17:45:02.0000] <webben_>
including other options for filtering searches perhaps

[17:47:00.0000] <zcorpan>
given that there already is an implementation, and that search fields are almost always text anyway, i think it's better to use type=search

[17:48:00.0000] <Hixie>
what would it do?

[17:48:01.0000] <zcorpan>
be easy to find as a search field

[17:48:02.0000] <Hixie>
why doesn't class=search do that?

[17:49:00.0000] <Hixie>
given that class=search automatically makes this work with existing content

[17:49:01.0000] <Hixie>
i don't understand why you would want to overload type="" for this

[17:49:02.0000] <Hixie>
note that webkit's type=search does other things than just make it seekable

[17:50:00.0000] <zcorpan>
yeah, but that isn't incompatible with not doing those things, right?

[17:50:01.0000] <Hixie>
it's still dangerous to walk all over the extensions

[17:50:02.0000] <zcorpan>
perhaps

[17:50:03.0000] <Hixie>
i don't understand what's wrong with seeking to class=search

[17:51:00.0000] <Hixie>
given that it's more widely used

[17:51:01.0000] <zcorpan>
nothing wrong with it

[17:51:02.0000] <Hixie>
so why is type=search better?

[17:51:03.0000] <zcorpan>
it has an implementation :)

[17:51:04.0000] <Hixie>
where?

[17:51:05.0000] <zcorpan>
safari

[17:51:06.0000] <Hixie>
no, that's an implementation of other behavour, not of the seeking you're trying to solve.

[17:51:07.0000] <tantek>
FWIW, at technorati.com we use  <input id="search" ...

[17:51:08.0000] <webben_>
Hixie: Also, for the same reasons class-based approaches will always receive opposition.

[17:52:00.0000] <Hixie>
webben_: class-based approaches don't receive opposition when you do them using the microformats process

[17:52:01.0000] <othermaciej>
what do you mean by seekable?

[17:52:02.0000] <Hixie>
(unless they're a bad idea)

[17:52:03.0000] <zcorpan>
Hixie: it renders them distinctly, so for visual users they are easier to find than normal text fields

[17:52:04.0000] <bewest>
(in which case they shouldn't make it through the mf process)

[17:53:00.0000] <othermaciej>
I think our <input type="search"> is useful

[17:53:01.0000] <webben_>
Hixie: Microformats are very different in that most of the successful formats either misuse elements in unusual ways (abbr/title) or "namespace" the classes using an unnatural class name (e.g. hCard, hAtom)

[17:53:02.0000] <othermaciej>
it changes the control appearance and behavior

[17:53:03.0000] <othermaciej>
having class do that would be weird

[17:53:04.0000] <Hixie>
othermaciej: i agree that if the idea is to change the behaviour, then a new type is worthy

[17:53:05.0000] <othermaciej>
and I'm not sure how you could overlay arbitrary input types with also having all the search properties

[17:54:00.0000] <othermaciej>
(it draws in a distinctive style, saves recent searches, etc)

[17:54:01.0000] <Hixie>
othermaciej: zcorpan said the problem he was trying to solve was simply that of making the search field targettable by shortcut

[17:54:02.0000] <webben_>
Hixie: I think heuristics for finding search need to be distinguished from explicitly marking search.

[17:54:03.0000] <Hixie>
zcorpan: for which the type doesn't make sense imho

[17:54:04.0000] <tantek>
and auto-targeting/focusing an input field is orthogonal from search

[17:55:00.0000] <webben_>
falling back on class="search" or id="search" is more appropriate for an AT trying to guess where the search is

[17:55:01.0000] <Hixie>
auto-targeting/focusing an input field is already handled by autofocus=""

[17:55:02.0000] <othermaciej>
zcorpan, annevk: you can probably get help on this from Adele from the WebKit team if you want to write up how our search field works

[17:55:03.0000] <Hixie>
webben_: i'm just saying that we should make sure that we correctly determine what problem we're trying to solve and then consider the various options in that light

[17:55:04.0000] <webben_>
Hixie: No disagreement there. :)

[17:55:05.0000] <othermaciej>
well, if the idea is to have a keyboard shortcut to pick the search field, then you probably need a number of potential candidates:

[17:56:00.0000] <othermaciej>
1) <input type="search"> fields, since intent there is clear without a class

[17:56:01.0000] <zcorpan>
Hixie: i didn't mean only accessible with keyboard shortcut, but more identifiable as a search field

[17:56:02.0000] <othermaciej>
2) input fields that have class="search" (maybe - is this actually common on an input, not a form?)

[17:56:03.0000] <othermaciej>
3) some heuristically determined text input in a form with class="search"

[17:56:04.0000] <webben_>
I think the focus on inputs here is wrong, because many search queries involve more than one input.

[17:57:00.0000] <webben_>
the focus should be on <form type/class="search">

[17:57:01.0000] <othermaciej>
there are a lot of search forms that are based on a single search field

[17:57:02.0000] <othermaciej>
and distinguishing the field in such cases visually and adding special behavior is useful

[17:57:03.0000] <zcorpan>
yeah. this isn't for complex searches

[17:57:04.0000] <webben_>
othermaciej: Of course. But those are also handled by distinguishing <form>.

[17:57:05.0000] <Hixie>
personally i'm not really convinced there's a problem to solve here, but i haven't looked at it closely

[17:57:06.0000] <webben_>
zcorpan: but for AT navigation, you want to handle complex search areas on a page too

[17:57:07.0000] <othermaciej>
webben_: have you seen how <input type="search"> works in Safari?

[17:58:00.0000] <webben_>
othermaciej: what's an example page that uses it?

[17:58:01.0000] <webben_>
(i've got safari here)

[17:58:02.0000] <zcorpan>
webben_: for complex searches, you generally have a page dedicated for that specifically

[17:58:03.0000] <othermaciej>
webben_: http://www.apple.com/

[17:58:04.0000] <webben_>
zcorpan: I've seen plenty of pages with more than one input in the search area on a page not dedicated to search

[17:58:05.0000] <othermaciej>
webben_: it looks distinctive and remembers past searches

[17:59:00.0000] <zcorpan>
webben_: pointer?

[17:59:01.0000] <webben_>
zcorpan: I can try and find you some examples if that would help.

[18:00:00.0000] <othermaciej>
anyway, you wouldn't want to do the extra appearance and behavior on any input field that's inside a <form class="search">

[18:00:01.0000] <webben_>
zcorpan: http://ubuntuforums.org/ springs to mind

[18:00:02.0000] <webben_>
othermaciej: That's the difference between search and keywords.

[18:00:03.0000] <othermaciej>
and if you had a feature to "find the search field", it would be perverse for it to ignore an <input type="search"> that doesn't happen to be in a form with the right class

[18:00:04.0000] <webben_>
safari's search is /really/ a keywords field

[18:01:00.0000] <webben_>
othermaciej: Sure. But that's a matter of heuristics.

[18:01:01.0000] <webben_>
(and with type, there's no huge harm in making special treatment a requirement, even if search isn't made a conforming value)

[18:02:00.0000] <othermaciej>
well, I think it's clear that if it is worth identifying something on the page as "the search field" and to have a spec for it, <input type="search"> should be included

[18:02:01.0000] <othermaciej>
the question is then what other things, if any, would need to be identified

[18:02:02.0000] <webben_>
/me agrees it's worth including. But then he also thinks it's worth including <acronym>.

[18:03:00.0000] <zcorpan>
webben_: that page has two separate simple search fields?

[18:03:01.0000] <webben_>
zcorpan: click search to see the search form

[18:04:00.0000] <webben_>
(it's a dropdown)

[18:04:01.0000] <webben_>
you control what form you want results returned in

[18:04:02.0000] <zcorpan>
show in threads / show in posts ?

[18:05:00.0000] <othermaciej>
I don't think the auxiliary radio buttons here would conflict with <input type="search"> as a way to find the search field

[18:05:01.0000] <webben_>
zcorpan: yeah

[18:05:02.0000] <zcorpan>
othermaciej: agreed

[18:05:03.0000] <othermaciej>
the case where it breaks down is if you have multiple text inputs

[18:05:04.0000] <othermaciej>
or something like a date range picker

[18:06:00.0000] <webben_>
othermaciej: does Safari or VO offer any navigation shortcut to type=search

[18:06:01.0000] <webben_>
can either cycle between multiple instances of that type?

[18:07:00.0000] <othermaciej>
Safari doesn't, no

[18:07:01.0000] <othermaciej>
I think VO does distinguish search fields from garden-variety text fields though

[18:08:00.0000] <webben_>
othermaciej: it would probably be worth getting a clear description of how it's currently used

[18:09:00.0000] <othermaciej>
webben_: it's not primarily an accessibility feature

[18:10:00.0000] <webben_>
othermaciej: That doesn't matter. If current AT makes use of it in any way, that needs to be documented for considering how to treat it in the spec.

[18:10:01.0000] <Hixie>
othermaciej doesn't care about accessibility!!!11

[18:10:02.0000] <webben_>
e.g. it would be interesting to know if there is a Search input in Apple's Accessibility API

[18:11:00.0000] <webben_>
(it's important to have some sync between desktop accessibility APIs and HTML applications)

[18:11:01.0000] <othermaciej>
webben_: HTML5 in general doesn't spec how AT treats various form controls

[18:11:02.0000] <othermaciej>
sounds like it would be worthy research, but I don't volunteer to do it

[18:12:00.0000] <webben_>
othermaciej: But how UAs treat form controls is what we're discussing here, isn't it?

[18:12:01.0000] <webben_>
which obviously includes AT?

[18:12:02.0000] <webben_>
we don't seem to be having an abstract discussion of semantics

[18:12:03.0000] <othermaciej>
I'm actually not sure what the point of contention is - I just wanted to explain why I think <input type="search"> is a generally useful feature

[18:13:00.0000] <othermaciej>
I don't know any more about the details of how VoiceOver treats it than I do about how VoiceOver treats <input type="text">

[18:13:01.0000] <webben_>
othermaciej: it would be useful because UAs can make use of it ... hence my question of what use UAs do make of it.

[18:14:00.0000] <othermaciej>
Safari makes use of it by giving it a distinctive appearance (rounded ends, search icon on one side) and behavior (menu of previous searches) and probably some other stuff I am forgetting

[18:14:01.0000] <webben_>
(of course UAs could presumably make /more/ use of it too)

[18:14:02.0000] <othermaciej>
how VO makes use of it, I don't know offhand

[18:15:00.0000] <othermaciej>
we don't have a "find the search field" feature, I imagine it could be cool, but the distinctive look makes it easy for a sighted user at least to spot while scanning the page

[18:15:01.0000] <webben_>
othermaciej: is the menu URL specific or general to all search boxes?

[18:15:02.0000] <othermaciej>
I'm not sure what you mean by 'menu URL'

[18:16:00.0000] <webben_>
sorry, I mean the menu of previous searches, does Safari lump all search boxes together when presenting a menu

[18:16:01.0000] <webben_>
or remember searches for each instance or each URL or what?

[18:19:00.0000] <zcorpan>
/me updated the document

[18:19:01.0000] <othermaciej>
I think it's distinct per search field

[18:19:02.0000] <othermaciej>
http://www.searchmash.com/ is another field that uses it

[18:20:00.0000] <othermaciej>
(another site that uses it)

[18:20:01.0000] <Hixie>
mmmm

[18:20:02.0000] <Hixie>
searchmash.com

[18:20:03.0000] <Hixie>
wonder what that could be!

[18:20:04.0000] <othermaciej>
it's not-so-secretly a "web 2.0" version of google search

[18:21:00.0000] <Hixie>
indeed

[18:21:01.0000] <othermaciej>
I know I've seen it on other sites but I can't think of examples offhand

[18:22:00.0000] <Hixie>
basically it looks different and has a button to clear the field, as far as i can tell

[18:22:01.0000] <othermaciej>
the searchmash one isn't using the menu of saved searches feature

[18:22:02.0000] <aroben>
Hixie: othermaciej: facebook.com uses it

[18:22:03.0000] <othermaciej>
oh that's right

[18:22:04.0000] <othermaciej>
and facebook uses the Recent Searches feature

[18:23:00.0000] <aroben>
othermaciej: webben_: the recent searches are made unique by the autosave attribute

[18:24:00.0000] <Hixie>
how do i see these recent searches?

[18:24:01.0000] <aroben>
othermaciej: webben_: <input type="search" autosave="unique_identifier">

[18:24:02.0000] <aroben>
Hixie: do some searches using the field

[18:24:03.0000] <aroben>
Hixie: then click on the magnifying glass

[18:24:04.0000] <webben_>
othermaciej: so couldn't one decouple autosave and type="search"?

[18:24:05.0000] <aroben>
Hixie: a menu should pop up

[18:24:06.0000] <Hixie>
aroben: tried that

[18:24:07.0000] <zcorpan>
why isn't name="unique_identifier" good enough for that feature?

[18:24:08.0000] <Hixie>
aroben: on apple.com didn't work

[18:25:00.0000] <aroben>
Hixie: apple.com isn't saving any search results

[18:25:01.0000] <Hixie>
ah

[18:25:02.0000] <Hixie>
i don't have a facebook account

[18:25:03.0000] <aroben>
Hixie: the magnifying glass has a little down arrow next to it if will save results

[18:25:04.0000] <webben_>
autosave sounds weirdly similar to IE's autocomplete

[18:25:05.0000] <Hixie>
so what makes the magnifying glass appear?

[18:26:00.0000] <aroben>
Hixie: http://www.37signals.com/svn/archives2/searchin_safari.php

[18:26:01.0000] <Hixie>
doesn't answer the question :-)

[18:26:02.0000] <aroben>
Hixie: just showing you the picture

[18:26:03.0000] <Hixie>
searchmash doesn't have a magnifying glass

[18:26:04.0000] <Hixie>
apple does

[18:26:05.0000] <aroben>
Hixie: the magnifying glass is controlled by the results attribute

[18:26:06.0000] <webben_>
I quite like the idea of a default presentation for search fields. It's worth noting that attaching a default presentation might well drive some publishers to avoid using it though.

[18:27:00.0000] <webben_>
(in favour of their own search icons or whatever)

[18:27:01.0000] <Hixie>
aroben: which does what?

[18:27:02.0000] <tantek>
indeed, publishers make <div> javascript buttons for that reason

[18:27:03.0000] <webben_>
it may be that providing CSS for adding an icon for fields, and distributing copyleft images for a search magnifying glass would wok better

[18:27:04.0000] <aroben>
Hixie: you can have results="10" to specify that 10 results should be saved

[18:27:05.0000] <webben_>
(a bit like the Feed icons)

[18:27:06.0000] <Hixie>
aroben: seems silly to show the magnifying glass if nothing's gonna be saved :-)

[18:27:07.0000] <tantek>
but if Safari supported more of CSS3UI, then publishers could customize the look & feel of controls better

[18:28:00.0000] <aroben>
Hixie: yes, but that's the OS X convention

[18:29:00.0000] <Hixie>
aroben: so why not show it always?

[18:29:01.0000] <karlUshi>
/me wonders if the list is YOUR own previous search requets on the site. So it means the browser has an individual list for each site having this markup. And is it by site (domain name) or by individual web page? 

[18:29:02.0000] <aroben>
Hixie: not sure, honestly

[18:29:03.0000] <karlUshi>
A lot of issues

[18:30:00.0000] <aroben>
Hixie: the rule is: if there's no results attribute, you get no magnifying glass

[18:30:01.0000] <webben_>
so we're talking two extra attributes as well as a new type

[18:30:02.0000] <aroben>
Hixie: if there's an empty results attribute or it has the value 0, there's a magnifying glass with no arrow and no menu

[18:30:03.0000] <aroben>
Hixie: if there's a results attribute with value > 0, there's a magnifying glass, arrow, and menu

[18:30:04.0000] <Hixie>
aroben: seems weird :-)

[18:31:00.0000] <zcorpan>
why aren't searches always saved? with some appropriate number of shown results? with the identifier being the name=""?

[18:31:01.0000] <webben_>
a unique autosave id makes sense to me

[18:31:02.0000] <webben_>
agree with zcorpan about results

[18:31:03.0000] <webben_>
don't understand what either has to do (intrinsically) with search

[18:32:00.0000] <aroben>
zcorpan: I don't know all the reasons behind the current design

[18:32:01.0000] <webben_>
e.g. autosave functionality would also be useful for data entry

[18:32:02.0000] <zcorpan>
normal text fields remember what was typed in based on name=""... i don't see why search fields should be different

[18:32:03.0000] <aroben>
webben_: you mean similar to most browser's autocomplete feature?

[18:32:04.0000] <aroben>
*browsers'

[18:33:00.0000] <webben_>
aroben: I don't really know how those features work, so I'm not sure.

[18:33:01.0000] <webben_>
in particular, how granular their memory is

[18:33:02.0000] <aroben>
webben_: I believe it's what zcorpan is referring to

[18:33:03.0000] <zcorpan>
yeah

[18:33:04.0000] <zcorpan>
how is autosave different?

[18:33:05.0000] <zcorpan>
and why

[18:34:00.0000] <aroben>
zcorpan: I'm not sure there's any deep reason behind the separation

[18:34:01.0000] <aroben>
zcorpan: clearly autocomplete can work nicely for search fields, as with the search field in the Firefox chrome

[18:34:02.0000] <zcorpan>
indeed

[18:34:03.0000] <webben_>
.

[18:35:00.0000] <webben_>
i thought that was Google Suggest powering that

[18:35:01.0000] <webben_>
maybe it's a combination of the two

[18:35:02.0000] <aroben>
webben_: Google Suggest is there, yes, but it will also just remember things you've typed in before

[18:35:03.0000] <aroben>
webben_: right

[18:36:00.0000] <webben_>
it sounds like autocomplete, autosave, and our autocompletion-WF2 stuff all needs to be considered together

[18:37:00.0000] <webben_>
as it's all trying to manipulate the same functionality from the server

[18:38:00.0000] <zcorpan>
i understand the autosave feature, but i don't understand why it needs any attributes for it to work

[18:38:01.0000] <webben_>
it doesn't sound as though type=search shares searches between multiple sites, which in theory could be useful (as in, "i didn't find anything about X on this site, but now I'll go search for X on this other site")

[18:39:00.0000] <Lachy>
good morning

[18:39:01.0000] <webben_>
morning Lachy

[18:39:02.0000] <zcorpan>
good night

[18:39:03.0000] <zcorpan>
:)

[18:39:04.0000] <Lachy>
Hixie: what did you mean by "lordy, poor lachy"?

[18:40:00.0000] <Hixie>
webapi

[18:40:01.0000] <aroben>
webben_: it does share between sites

[18:41:00.0000] <aroben>
webben_: all that matters is the autosave attribute

[18:41:01.0000] <aroben>
webben_: which is probably why we didn't go with name=""

[18:41:02.0000] <webben_>
aroben: sorry, i meant between sites where the authors didn't intended to share searches like that

[18:41:03.0000] <Lachy>
oh, the objections to the names? Just reading those now

[18:42:00.0000] <webben_>
(e.g. I search for something on Google, then give up and search for it on Microsoft Live.com)

[18:42:01.0000] <Hixie>
Lachy: yeah. luckily nobody is trying to change the decision, but sheesh. talk about illustrating the difference between the w3c and the whatwg.

[18:42:02.0000] <aroben>
webben_: yes, that's what I'm talking about

[18:42:03.0000] <aroben>
webben_: if google.com and live.com use the same autosave attribute, you'll get shared recent searches

[18:42:04.0000] <Hixie>
isn't that a privacy risk?

[18:42:05.0000] <webben_>
aroben: are so the intention is that competitors will use the same autosave id?

[18:43:00.0000] <aroben>
Hixie: through user error, I suppose

[18:43:01.0000] <aroben>
Hixie: there's no access to the recent searches through the DOM

[18:43:02.0000] <Hixie>
aroben: you can easily trick users to click in different places

[18:43:03.0000] <aroben>
Hixie: right

[18:43:04.0000] <aroben>
webben_: I suppose so

[18:43:05.0000] <zcorpan>
aroben: and that is just as likely as that they use the same name="", no?

[18:43:06.0000] <aroben>
zcorpan: right

[18:43:07.0000] <zcorpan>
ok. anyway, i was going to bed

[18:43:08.0000] <zcorpan>
nn

[18:44:00.0000] <aroben>
zcorpan: I think the nice thing about having a separate attribute is that autosave isn't tied up in POST/GET requests

[18:44:01.0000] <webben_>
me too

[18:44:02.0000] <webben_>
good night folks

[18:44:03.0000] <aroben>
night zcorpan, webben_ 

[18:46:00.0000] <aroben>
Hixie: overall I think the desire was to mimic the functionality of NSSearchField

[18:47:00.0000] <Lachy>
yeah, it's quite annoying.  I clearly addressed all the arguments (though I didn't specifically reference the F2F minutes), yet I get accused of ignoring and treating people unfairly :-(

[18:48:00.0000] <Hixie>
Lachy: welcome to the world of spec editor

[18:48:01.0000] <Hixie>
Lachy: the only way around it is to make crappy compromises which make for a crappy spec

[18:49:00.0000] <Lachy>
I really don't want to compromise on gEBS, it'll just make another group of people unhappy

[20:05:00.0000] <Hixie>
does everyone agree that the tokeniser has 32 states now?

[20:05:01.0000] <Hixie>
or did i miscount

[20:06:00.0000] <Hixie>
like a dozen of them are just for the doctype

[20:06:01.0000] <Hixie>
sheesh

[20:56:00.0000] <aroben>
Hixie: one potential situation I thought of where you'd want an autosave attribute instead of a name attribute

[20:57:00.0000] <aroben>
Hixie: would be if you had two search fields on a page that you wanted to have share recent searches

[20:59:00.0000] <Hixie>
makes sense

[21:01:00.0000] <aroben>
Hixie: did input type=search show up in a spec recently?

[21:01:01.0000] <Hixie>
not one of mine

[21:01:02.0000] <aroben>
Hixie: just wondering what sparked the discussion

[21:01:03.0000] <Hixie>
http://simon.html5.org/temp/search-control.htm

[21:01:04.0000] <Hixie>
i don't know what the background was though

[21:02:00.0000] <aroben>
Hixie: do you know what "The autosave and results attributes have been identified as misnormers." means?

[21:06:00.0000] <Hixie>
no

[21:50:00.0000] <Hixie>
oops

[21:50:01.0000] <Hixie>
225 compiler errors

[00:23:00.0000] <webben>
Lachy: If you care to reread http://joeclark.org/book/sashay/serialization/Chapter13.html , you'll find Clark would certainly not favour removing the ability to provide transcription as an alternative to video.

[00:24:00.0000] <webben>
Full-fledged captioning, subtitles, audio description, and signing being preferable is not the same as transcription being useless.

[00:25:00.0000] <webben>
Indeed, Clark says that including a transcription is helpful even with those things (and easy to produce as part of the process.)

[00:29:00.0000] <webben>
What Clark does discourage in that chapter is not transcription per se but text (rather than audio) description for the blind.

[00:37:00.0000] <Hixie>
ok, i give up

[00:37:01.0000] <Hixie>
i've been trying to ignore it for all this time, but i finally broke down

[00:37:02.0000] <Hixie>
what the hell is the subject line "the market hasn't spoken - it hasn't bothered to listened" supposed to mean?

[00:37:03.0000] <Hixie>
is it supposed to be "to listen" or is it supposed to be "to be listened to"?

[00:38:00.0000] <hsivonen>
Hixie: "to listen"

[00:38:01.0000] <gavins>
hmm, I'd always read it as "the market has spoken, no one's bothered to listen"

[00:38:02.0000] <Hixie>
gavins: yeah, hence my confusion

[00:38:03.0000] <Hixie>
who hasn't listened?

[00:38:04.0000] <hsivonen>
Hixie: the market

[00:38:05.0000] <Hixie>
what haven't they listened to?

[00:38:06.0000] <hsivonen>
Hixie: the accessibility folk

[00:39:00.0000] <Hixie>
i see

[00:39:01.0000] <Hixie>
isn't it the accessibility folk (and in fact all of us spec people) who are the ones who are supposed to listen?

[00:39:02.0000] <hsivonen>
no comment

[00:41:00.0000] <gavins>
oh, I get it now

[00:41:01.0000] <gavins>
(reading his actual message helped)

[02:52:00.0000] <hsivonen>
aargh. the anon access of the whattf repo is broken again

[08:08:00.0000] <krijnh>
Ping

[12:28:00.0000] <zcorpan_>
hmm, perhaps i should add more tests that check EOF handling in pseudo-comments

[12:29:00.0000] <zcorpan_>
to make sure that we don't do funny stuff like reparsing :)

[12:59:00.0000] <zcorpan_>
naw, reparsing would be a separate bug

[13:33:00.0000] <bewest>
launching on a friday?

[13:39:00.0000] <zcorpan_>
http://intertwingly.net/blog/2007/06/28/Publishing-a-Blog-From-a-mod-atom-Store

[13:56:00.0000] <bewest>
mod_atom?

[13:58:00.0000] <zcorpan_>
when i posted the link, the page wasn't well-formed

[14:00:00.0000] <zcorpan_>
Planet&#8217;'s was Planet&#8217's

[14:28:00.0000] <zcorpan_>
othermaciej: [13:22] <zcorpan> om_sleep: forgot to end your sentence again?  http://www.w3.org/mid/E40DB09C-1333-4FC2-B9E0-A83CADE75C4E⊙ac

[14:31:00.0000] <othermaciej>
zcorpan_: yeah, I did, I hope my point was clear

[14:32:00.0000] <zcorpan_>
", then that would be great." ? :)

[14:42:00.0000] <othermaciej>
yeah

[15:02:00.0000] <Hixie>
my parser is unfortunately not re-entrant

[15:02:01.0000] <Hixie>
which is making it hard to process " " characters in the trailing end phase exactly per spec without duplicating code

[15:26:00.0000] <zcorpan_>
http://forums.whatwg.org/viewtopic.php?t=70

[15:31:00.0000] <Hixie>
zcorpan_: commented

[15:39:00.0000] <met_>
hsivonen: why is Konqueror blank for HTML5 on http://hsivonen.iki.fi/doctype/ ?

[15:39:01.0000] <hsivonen>
met_: because I have not tested

[15:40:00.0000] <met_>
I have some virtuals with Konq, have you some test which I can try?

[15:40:01.0000] <met_>
or it is more complicated?

[15:41:00.0000] <hsivonen>
met_: the leftmost cell on each row link to a test

[15:41:01.0000] <met_>
thanks 8-)

[15:42:00.0000] <Philip`>
If I remember correctly, Konq 3.5 was identical to "Moz & Safari" on all of those tests

[15:43:00.0000] <met_>
/me hasn't runed his openSUSE virtual for month, it is checking file system 8-(

[15:51:00.0000] <met_>
ok it's Konq 3.5.5

[15:53:00.0000] <met_>
hsivonen:  it's the blue rectagles test? (according to safari, there is no note about Konq)

[15:55:00.0000] <hsivonen>
Philip`: oops. I've forgotten to act on that report

[15:55:01.0000] <hsivonen>
Philip`: sorry

[15:55:02.0000] <met_>
probably not exactly, I see some differences from the Konq 3.2 you have there

[15:55:03.0000] <hsivonen>
met_: the blue rectangles tests full standards vs. something else

[15:57:00.0000] <hsivonen>
Philip`: fixed

[15:57:01.0000] <hsivonen>
Philip`: thanks

[15:57:02.0000] <met_>
donot work, If I went throug Konq3.2 column I see different results even for some quirks

[15:58:00.0000] <hsivonen>
met_: do you still have Konq 3.2?

[15:59:00.0000] <met_>
no 3.5.5 (mentioned above), there was something fixed probably

[15:59:01.0000] <met_>
not usefull for you

[15:59:02.0000] <hsivonen>
met_: most likely they landed the code hyatt adapted from Gecko way back in the Safari 1.0 cycle

[16:00:00.0000] <hsivonen>
or 0.9 rather

[16:02:00.0000] <met_>
I see even difference between XHTML transitional and strict, you have both Q

[16:06:00.0000] <hsivonen>
met_: Konq 3.2 is 3.2. Moz & Safari is 3.5

[16:07:00.0000] <met_>
yes I have just tested whole table Konq 3.5.5 is exactly like Moz+Saf column

[16:19:00.0000] <met_>
2004-10-28  Stephan Kulow  <coolo⊙ko>

[16:19:01.0000] <met_>
        * html/html_documentimpl.cpp (determineParseMode): adding a fixed list of

[16:19:02.0000] <met_>
        doctypes to enable quirks mode on (derived from Webcore, but majorly revised)

[16:19:03.0000] <met_>
        * enable strict CSS parsing also for transitional doctypes

[16:19:04.0000] <met_>
from http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/ChangeLog?view=markup&pathrev=632575

[16:20:00.0000] <met_>
2004 it's pretty old

[16:20:01.0000] <hsivonen>
met_: thanks

[16:21:00.0000] <hsivonen>
I wonder how the ICU4J encoding detector differs from Mozilla chardet

[16:22:00.0000] <met_>
and here is the KHTML source function HTMLDocumentImpl::determineParseMode http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp?revision=628618&view=markup

[16:23:00.0000] <met_>
khml has even different file names from webkit source - it has to be nightmare with merging

[16:24:00.0000] <hsivonen>
why the difference in file names?

[16:28:00.0000] <met_>
html_documentimpl.cpp from KHTML is HTMLDocument.cpp in webkit

[16:28:01.0000] <met_>
different convention probably 

[16:33:00.0000] <met_>
Does anyone know, why Safari sents to flick and yahoo different uastring?

[16:35:00.0000] <met_>
it tries to look as older version for this domains, it's harcoded in http://www.koders.com/noncode/fid469663037C7D987803483ECADC6068A0AD6B40F2.aspx#L3579

[16:37:00.0000] <hsivonen>
met_: I don't know but it isn't hard to guess why. most likely Yahoo is doing bad UA sniffing

[16:38:00.0000] <hsivonen>
or then they are doing good UA sniffing to work around a WebKit bug and the new WebKit doesn't fix the bug

[16:38:01.0000] <met_>
hsivonen: it is much different

[16:39:00.0000] <hsivonen>
yes

[16:39:01.0000] <met_>
only in version number

[16:39:02.0000] <met_>
and also send Macintosh even if i work on Windows

[16:40:00.0000] <met_>
oh so late, going to sleep, bye


2007-06-29
[17:30:00.0000] <Hixie>
so... determining if headers="" is correctly-used or not

[17:38:00.0000] <Hixie>
http://www.brera.unimi.it/old/CAELUM/MUSEO/Schede/rif32.html

[17:38:01.0000] <Hixie>
i know it says "old" in the URL, but uh, were there even _computers_ in 1939?!

[17:39:00.0000] <othermaciej>
do ENIGMA-cracking machines count?

[17:39:01.0000] <Hixie>
only if the data on those machines was written in HTML

[17:39:02.0000] <Hixie>
(that HTML file has a "last modified" date of 1939)

[17:59:00.0000] <zcorpan_>
typo of 1993?

[18:00:00.0000] <Hixie>
why would you type the last modified date?

[18:00:01.0000] <zcorpan_>
dunno

[18:26:00.0000] <hober>
ImproperlyConfigured: Error loading MySQLdb module: No module named MySQLdb

[18:26:01.0000] <hober>
whoops, sorry for the noise.

[18:28:00.0000] <zcorpan_>
hmm, i think firefox has funny handling of -- in doctypes

[18:29:00.0000] <Hixie>
not "funny"

[18:29:01.0000] <Hixie>
"compliant to SGML"

[18:29:02.0000] <Hixie>
i opted to drop that in the spec's version, you'll be glad to notice

[18:30:00.0000] <zcorpan_>
not quite compliant to sgml... <!doctype html --> foo -- system>

[18:31:00.0000] <Hixie>
heh

[18:31:01.0000] <Hixie>
fair enough

[18:31:02.0000] <Lachy>
zcorpan_: are comments allowed in DOCTYPEs like that?  I don't think so

[18:31:03.0000] <zcorpan_>
Lachy: per sgml, yes

[18:32:00.0000] <Lachy>
I thought only within the internal subset, not before the sys ident like that

[18:32:01.0000] <Hixie>
in any sgml declaration

[18:32:02.0000] <Hixie>
the doctype is an sgml declaration

[18:32:03.0000] <zcorpan_>
what Hixie said

[18:32:04.0000] <Hixie>
at least that's my understanding

[18:32:05.0000] <Hixie>
it's mostly academic in practice

[18:32:06.0000] <Lachy>
oh, right.  anyway, doesn't matter

[18:33:00.0000] <zcorpan_>
indeed

[18:35:00.0000] <Hixie>
ok so for my study of longdesc="", i'm looking for these things:

[18:35:01.0000] <Hixie>
* does the <img> not have a longdesc at all?

[18:35:02.0000] <Hixie>
* is its longdesc blank?

[18:35:03.0000] <Hixie>
* does its longdesc have a spec character in it?

[18:35:04.0000] <Hixie>
* does its longdesc value match the href="" of an ancestor <a> element?

[18:35:05.0000] <Hixie>
anything else i should look for?

[18:36:00.0000] <zcorpan_>
* does it's longdesc point to the same page or a fragment on the same page?

[18:36:01.0000] <Lachy>
could you also check if it matches an href anywhere in the document, if there isn't an ancestor link?

[18:36:02.0000] <Lachy>
or at least nearby\

[18:37:00.0000] <zcorpan_>
given jaws implementation, same-page fragments with longdesc aren't usable at all

[18:37:01.0000] <Lachy>
the idea is to see if most people are willing to put [D] links, or equivalent in, despite having fairly wide AT support now

[18:38:00.0000] <Hixie>
ok i added a check to see if the attribute's value matches the page's url

[18:38:01.0000] <Hixie>
and a check to see if the value doesn't have a space in it but starts with a #

[18:38:02.0000] <Hixie>
do i need a check for whether the value is url+# ?

[18:39:00.0000] <zcorpan_>
probably not

[18:39:01.0000] <Lachy>
what could you conclude from url+#?

[18:39:02.0000] <Hixie>
i mean, the page's url + #

[18:39:03.0000] <Hixie>
ok

[18:39:04.0000] <Hixie>
now headers=""

[18:39:05.0000] <Hixie>
lordy

[18:39:06.0000] <Lachy>
oh, ok, I thought you meant just any URL.  But that would tell you longdescs to the same page

[18:44:00.0000] <csarven>
occording to this http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EmptyElemTag the trailing space on empty/null elements is optional. i can't remember correctly but was there anything about IE not interpreting the empty elements if there were no trailing spaces?

[18:45:00.0000] <csarven>
s/occording/according

[18:45:01.0000] <Hixie>
in XHTML? or in raw XML?

[18:45:02.0000] <Hixie>
IE doesn't support XHTML.

[18:45:03.0000] <Hixie>
but it handles raw XML pretty much per spec.

[18:46:00.0000] <csarven>
well XHTML is useless for IE so it doesn't make a difference either way right

[18:46:01.0000] <csarven>
im probably mistaken about this

[18:46:02.0000] <zcorpan_>
the trailing space mentioned in xhtml 1.0 appendix c is for NN4

[18:47:00.0000] <Lachy>
does NN4 really choke on it?

[18:47:01.0000] <csarven>
for some reason i thought that the trailing space that developers were putting on XHTML documents (served with text/html for IE) contained the trailing spaces.. i thought it was because IE didn't treat them properly when there was no trailing space

[18:47:02.0000] <Lachy>
I thought it was pre-NN4 browsers

[18:47:03.0000] <zcorpan_>
it treats it as part of the tag name

[18:47:04.0000] <Lachy>
they do because of the appendix c guideline, not because of IE

[18:48:00.0000] <Lachy>
there are no known widely used browsers that need the space these days

[18:48:01.0000] <zcorpan_>
<br foo=""/> probably works fine in nn4 though (it would just treat it as an attribute)

[18:50:00.0000] <csarven>
interesting. http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EmptyElemTag states its optional but appendix C suggests to use the trailing space

[18:51:00.0000] <Lachy>
There are, unfortunately, still some people in the world who use NN4. There was a question on the WSG list recently by someone with a project that had to support Windows 3.1 and NN4 :-/

[18:51:01.0000] <Lachy>
I think it was some intranet project

[18:51:02.0000] <Hixie>
csarven: i highly recommend using text/html and forgetting about XML for the purposes of XHTML :-)

[18:52:00.0000] <Lachy>
csarven: keep in mind that appendix c is non-normative and is based upon unknown research on ancient browsers.

[18:53:00.0000] <zcorpan_>
...and has conflicting guidelines

[18:53:01.0000] <csarven>
perhaps this is the unclear part for me.. is XHTML not entirely XML? :S

[18:53:02.0000] <zcorpan_>
(don't use PIs, use PIs)

[18:53:03.0000] <Lachy>
it is, but it just has guidlines for authors wanting to make it compatible with legacy UAs as text/html

[18:53:04.0000] <csarven>
Hixie oh this is just for curiosity :)

[18:53:05.0000] <Hixie>
ah :-)

[18:54:00.0000] <csarven>
good point Lachy

[18:54:01.0000] <csarven>
zcorpan_ :)

[18:54:02.0000] <Lachy>
the guidlines can be mostly ignored, though

[18:54:03.0000] <Lachy>
zcorpan_: the conflict is that it says to use <?xml?> decl, but don't use PIs because of the <?foo?> syntax

[18:56:00.0000] <zcorpan_>
Lachy: C.1 vs C.14

[18:56:01.0000] <Lachy>
yeah, I think so

[18:56:02.0000] <zcorpan_>
though C.14 is about when serving as xml, not text/html

[18:57:00.0000] <Lachy>
oh, I see, I got it backwards.

[18:57:01.0000] <Lachy>
It says don't use <?xml?>, but use <?xml-stylesheet?>

[18:58:00.0000] <Lachy>
then there's also the issue that <?xml-stylesheet?> doesn't define how to process stylesheets identified with a fragment ident.

[18:59:00.0000] <zcorpan_>
we need an Associating Style Sheets with XML documents 5

[19:00:00.0000] <zcorpan_>
or perhaps annevk will define that as part of xml5

[19:05:00.0000] <zcorpan_>
<?xml-stylesheet href="&#x41;"?>

[19:05:01.0000] <csarven>
zcorpan_ ASS?

[19:05:02.0000] <zcorpan_>
:)

[19:05:03.0000] <csarven>
has a nice ring to it

[19:05:04.0000] <zcorpan_>
ASS5

[19:11:00.0000] <othermaciej>
obviously you should name it Canonical ASS instead

[19:13:00.0000] <zcorpan_>
well there you go: opera expands NCRs in the pseudo-attributes, firefox doesn't

[19:13:01.0000] <zcorpan_>
not that the spec doesn't define that case though

[19:19:00.0000] <Lachy>
zcorpan_: which way does XML define it?

[19:19:01.0000] <Hixie>
sigh

[19:20:00.0000] <Hixie>
i'm gonna have to implement the Forming a Table algorithm aren't i

[19:20:01.0000] <Lachy>
Hixie, yeah

[19:21:00.0000] <Hixie>
so

[19:22:00.0000] <Hixie>
once i have these two tables constructed (one with headers and one without)

[19:22:01.0000] <Hixie>
how do i quantitatively compare them?

[19:22:02.0000] <Hixie>
just 1 for different and 0 for the same?

[19:32:00.0000] <othermaciej>
perhaps -1 for cases where the uses of headers is illegal and so might just confuse AT

[19:32:01.0000] <Hixie>
ah yes

[19:33:00.0000] <Hixie>
so i can count "incorrect", "redundant" and "interesting"

[19:49:00.0000] <Lachy>
Hixie, that low quality and high quality conformance idea you had gives a possible solution to the requirement of alt="".  Make it required in high quality, optional, but recommended, in low quality

[19:51:00.0000] <Lachy>
and probably call them Strict and Loose conformance

[20:29:00.0000] <Hixie>
Lachy: the names were carefuly chosen (and a big part of the proposal)

[20:29:01.0000] <Lachy>
ok

[22:30:00.0000] <Lachy>
I just realised that selectors api doesn't define a feature string for hasFeature(), while most (if not all) other DOM related specs do.  I'm not sure if it matters though.

[23:19:00.0000] <Hixie>
Lachy: see the whatwg spec for commentary on how useless that feature is :-)

[23:20:00.0000] <Lachy>
I know it's useless in JS, that's why I'm not rushing to add it.

[23:20:01.0000] <Lachy>
but I notice you include it for HTML5 and also XBL

[23:22:00.0000] <othermaciej>
hasFeature sucks

[23:22:01.0000] <othermaciej>
Selectors API is best tested for by property testing, at least in JS

[23:23:00.0000] <othermaciej>
but maybe less dynamic languages like Java don't have that luxury

[23:23:01.0000] <Lachy>
othermaciej: yeah, that's what I was wondering in #webapi

[00:15:00.0000] <Lachy>
for those of you who don't know yet, http://lachy.id.au/log/2007/06/opera :-)

[00:18:00.0000] <fishkandy>
Lachy, onya

[01:05:00.0000] <jruderman>
Lachy: what percentage of opera's new hires for the oslo office have to move from another country?

[01:11:00.0000] <Lachy>
jruderman: I have no idea

[01:12:00.0000] <jruderman>
Lachy: just wondering since i keep hearing about people moving to norway to work for opera

[01:12:01.0000] <othermaciej>
well, it's not like the world's top web experts already live in norway

[01:13:00.0000] <Lachy>
I've been told there's people from 41 different nationalities working there

[01:13:01.0000] <jruderman>
haha both apple and opera love The New York Times as an example site to show on a mobile phone

[01:14:00.0000] <othermaciej>
you should see how most phone browsers render it :-)

[01:16:00.0000] <jruderman>
hehe

[01:17:00.0000] <jruderman>
what do opera and safari do with simple fixed-width pages? do you have to scroll left and right as you read each line of a paragraph?

[01:17:01.0000] <jruderman>
(on phones)

[01:17:02.0000] <othermaciej>
in Mobile Safari you can pinch-zoom, pan, and double-tap to zeem a block of text to fit

[01:17:03.0000] <othermaciej>
*zoom

[01:17:04.0000] <othermaciej>
dunno what Opera does

[01:17:05.0000] <othermaciej>
I hate fixed-width pages

[01:18:00.0000] <othermaciej>
even on the desktop

[01:18:01.0000] <Lachy>
Opera has small screen rendering, which you can simulate in the desktop browser

[01:18:02.0000] <jruderman>
i don't want to zoom to fit the width of the block if that means each letter is 4px..

[01:19:00.0000] <Lachy>
I thinkthere's a video that demonstrates the web browser somewhere on the apple site

[01:19:01.0000] <jruderman>
they always demo with the new york times

[01:19:02.0000] <jruderman>
or google

[01:20:00.0000] <othermaciej>
jruderman: you'll have to try one or get someone to demo if you want to see

[01:21:00.0000] <othermaciej>
jruderman: could probably expense it for "competitive analysis"

[01:22:00.0000] <Lachy>
hmm. the apple site says the video is 175MB to download. It's actually 318MB http://www.apple.com/iphone/usingiphone/guidedtour.html

[02:26:00.0000] <zcorpan_>
Lachy: only the five entities are expanded in xml-stylesheet pseudo-attributes per ASS

[02:27:00.0000] <Lachy>
yeah, I only expected the 5 predefined entities to be expanded

[02:27:01.0000] <Lachy>
but is that true even if there's a doctype with an internal subset?

[02:28:00.0000] <Fuzzy76>
Lachy: Congratulations on your new job :)

[02:28:01.0000] <Lachy>
thanks

[02:28:02.0000] <zcorpan_>
Lachy: yes

[02:28:03.0000] <Lachy>
is that a browser limitation, or per spec?

[02:28:04.0000] <zcorpan_>
spec

[02:28:05.0000] <Lachy>
ok

[02:29:00.0000] <zcorpan_>
haven't tested throughly what browsers do, just did one basic test (with the NCR) and found that firefox and opera did different things

[02:30:00.0000] <zcorpan_>
i might try to get the spec updated too... it's not sane and leaves things undefined

[02:36:00.0000] <Lachy>
I have to write a 40 minute presentation on HTML5 before the 20th, and I'll be away from the 7th to the 15th.

[02:36:01.0000] <hsivonen>
Lachy: congrats on the job

[02:36:02.0000] <Lachy>
thanks

[02:38:00.0000] <Lachy>
... and I'll be working on the XBL primer on the 4th and 5th.  I am really going to struggle to find the time :-/

[02:41:00.0000] <hsivonen>
Hixie: Re: survey on longdesc: you should probably dereference the URI and check the content type of what is found

[02:41:01.0000] <hsivonen>
Hixie: considering the bogosity of longdesc pointing to an image

[02:43:00.0000] <zcorpan_>
hsivonen: could perhaps be checked by checking if it's the same as src=""? (there already is a check for same as parent <a href>)

[02:44:00.0000] <zcorpan_>
hmm. <!doctype html public ">">

[02:44:01.0000] <zcorpan_>
all browsers terminate the doctype at the first >

[02:49:00.0000] <annevk>
that'd be easy to fix in the spec

[02:49:01.0000] <zcorpan_>
yeah

[02:54:00.0000] <annevk>
"Clarify who is in charge of dropping BOMs. Hint: it's not the air force." :)

[02:56:00.0000] <hsivonen>
are 512 byte boundary charset meta tests available as individual files somewhere?

[02:57:00.0000] <hsivonen>
extra points if there are tests where a broken UTF-8 bytes requence lies across the 512 byte boundary

[02:57:01.0000] <hsivonen>
byte sequence even

[02:58:00.0000] <zcorpan_>
hsivonen: i think Hixie has some tests on that

[02:58:01.0000] <Hixie>
hsivonen: i can't, i have no network in this environment

[02:58:02.0000] <hsivonen>
Hixie: ok. not even metadata from Google cache?

[02:59:00.0000] <annevk>
http://hixie.ch/tests/adhoc/html/parsing/encoding/ has some tests

[03:00:00.0000] <hsivonen>
annevk: ok. I'll see if some of those are what I'm looking for

[03:02:00.0000] <Hixie>
hsivonen: not with the way i'm doing it

[03:02:01.0000] <hsivonen>
Hixie: ok

[03:03:00.0000] <Hixie>
when you start trying to do scans of billions of documents, things like looking up information in a database becoomes unscalable

[03:05:00.0000] <hsivonen>
I wonder if ia_archiver searches the Web depth first, breadth first or something else

[03:05:01.0000] <hsivonen>
for surveys you want to do breadth first, right, to diversify results given finite time?

[03:06:00.0000] <Hixie>
almost certainly (c), since when you run a spider of that scale you have to take into account rate of retrieval per-server

[03:07:00.0000] <annevk>
how about collecting the set of referenced docs and checking those later?

[03:07:01.0000] <Hixie>
annevk: re Jirka's "Parse errors are allowed to be corrected by parser:

[03:07:02.0000] <hsivonen>
it would be interesting to hook up my Java parser (once ready) to the IA crawler so that people outside google with reasonable CPU and network could do smallish surveys

[03:07:03.0000] <Hixie>
"

[03:07:04.0000] <Hixie>
annevk: HTML4 allowed it too

[03:07:05.0000] <zcorpan_>
<!doctypehtmlpublic"x">

[03:08:00.0000] <annevk>
Hixie, yeah, I don't think I'm going to bother though

[03:08:01.0000] <zcorpan_>
...has the name "HTML" and the FPI "x" in firefox

[03:08:02.0000] <Hixie>
zcorpan_: has the name "htmlpublic"a"" in the spec

[03:08:03.0000] <zcorpan_>
yeah

[03:09:00.0000] <hsivonen>
I wonder if any of the people who volunteered to survey the top sites are interested if getting the framework ready if I give an API spec for using the conformance checker development version

[03:09:01.0000] <Hixie>
bed time

[03:09:02.0000] <Hixie>
nn

[03:09:03.0000] <annevk>
night

[03:09:04.0000] <zcorpan_>
nn

[03:16:00.0000] <hsivonen>
ok. Hixie's tests 044, 045 and 046 are what I wanted

[03:18:00.0000] <zcorpan_>
ha! <!doctype html public "x>"> triggers standards mode in firefox (yet renders the "> characters in body), but <!doctype html public "x> triggers quirks mode

[03:18:01.0000] <annevk>
that shows the preparsing I guess

[03:18:02.0000] <zcorpan_>
yeah

[03:22:00.0000] <hsivonen>
w00t! Passed the tests on the first try after implementing something as complex as doing the buffering trickery around the 512 byte boundary

[03:22:01.0000] <zcorpan_>
hsivonen: nice :)

[03:26:00.0000] <zcorpan_>
hsivonen: why would you drop them on the floor?

[03:27:00.0000] <hsivonen>
zcorpan_: depends on whether you want to report null or a string that has prematurely ended

[03:27:01.0000] <hsivonen>
zcorpan_: on the face of it, reporting null makes sense if the string wasn't properly terminated

[03:28:00.0000] <hsivonen>
I now got the IBM UTF-8 decoder loaded instead of the Sun version. and now my code crashes

[03:28:01.0000] <hsivonen>
I wonder why

[03:29:00.0000] <zcorpan_>
hsivonen: well, the doctype's correctness flag is set to incorrect anyway...

[03:30:00.0000] <hsivonen>
Aargh. the IBM decoder does really wrong things when reporting UTF-8 errors

[03:38:00.0000] <zcorpan_>
oops

[03:39:00.0000] <zcorpan_>
ie doesn't terminate at > in FPI

[03:39:01.0000] <zcorpan_>
or in quotes anywhere

[03:39:02.0000] <annevk>
anywhere?

[03:39:03.0000] <annevk>
<! ">"?

[03:39:04.0000] <annevk>
<!-- "-->" --> ?

[03:39:05.0000] <zcorpan_>
those are not doctypes

[03:40:00.0000] <annevk>
no kididng

[03:40:01.0000] <zcorpan_>
but seems to apply to <! ">" > 

[03:40:02.0000] <zcorpan_>
not <!-- "-->" -->

[03:41:00.0000] <zcorpan_>
applies to <? ">" > and </ ">" > too

[03:42:00.0000] <zcorpan_>
<^_^>

[03:42:01.0000] <annevk>
fancy

[03:42:02.0000] <annevk>
seems like IE has the same handling for all of those

[03:42:03.0000] <annevk>
as it doesn't really support DOCTYPEs

[03:43:00.0000] <zcorpan_>
indeed

[03:51:00.0000] <hsivonen>
I wonder if Java 6 fixes the UTF-8 decoder holes

[03:51:01.0000] <hsivonen>
anyway, as of Java 5, both the JDK and ICU4J are b0rked

[04:48:00.0000] <annevk>
I wonder if the new encoding sniffer works for <meta> 512 bytes <meta> 512 bytes <meta> ...

[04:52:00.0000] <hsivonen>
annevk: "the new"?

[04:54:00.0000] <annevk>
the one that works together with the parser

[04:54:01.0000] <annevk>
and has this confident flag

[04:54:02.0000] <hsivonen>
annevk: is there a spec change?

[04:54:03.0000] <hsivonen>
annevk: or is this about html5lib?

[04:54:04.0000] <annevk>
there was a spec change

[04:55:00.0000] <annevk>
r955

[04:58:00.0000] <hsivonen>
what? did Hixie remove the magic 512 boundary?

[04:58:01.0000] <hsivonen>
just when I got it working

[04:59:00.0000] <annevk>
I think that boundary is still there for authors

[05:00:00.0000] <annevk>
actually

[05:02:00.0000] <annevk>
i think he did

[05:02:01.0000] <hsivonen>
/me is rather miffed

[05:07:00.0000] <zcorpan_>
hsivonen: you can perhaps use the code to emit a warning, suggesting that encoding declarations should be as early as possible in the source to improve perf (and interop?)

[05:08:00.0000] <hsivonen>
perhaps

[05:08:01.0000] <hsivonen>
I'm going to stop chasing encoding and tokenization spec changes for a while

[05:09:00.0000] <hsivonen>
I'd love to see a realistic spec on how much data to feed to chardet

[05:10:00.0000] <hsivonen>
that is, should I buffer the entire stream or n first bytes

[05:11:00.0000] <annevk>
i think guessing 512 bytes is reasonable

[05:11:01.0000] <annevk>
if you then later encounter a different encoding you'd have to switch

[05:12:00.0000] <hsivonen>
annevk: Gecko seems to run chardet on the first buffer the html parser gets from the channel but I have no idea how big that buffer is

[05:13:00.0000] <hsivonen>
/me hopes someone else finds out so that I don't need to find out using a debugger

[05:13:01.0000] <hsivonen>
what does IE do?

[05:13:02.0000] <hsivonen>
will a future WebKit use the ICU detector once it is ported to C?

[05:25:00.0000] <zcorpan_>
so the spec allows first a preparse, then a real parse, and then a real parse again if the first real parse found conflicting encoding information?

[05:27:00.0000] <zcorpan_>
e.g. <style><meta charset=utf-8></style><meta charset=windows-1252>

[05:28:00.0000] <annevk>
it seems to allow only a single preparse (optional) and only a single reparse

[05:28:01.0000] <hsivonen>
zcorpan_: but is the first "real" parse running scripts?

[05:31:00.0000] <hsivonen>
I don't trust that the current spec is the last word on this topic

[05:32:00.0000] <zcorpan_>
why is the preparse specced at all, if it yealds the same result as not preparsing (modulo perf)?

[05:32:01.0000] <hsivonen>
It would be nice if the people in charge of the relevant code in Trident, Gecko, WebKit and Presto just disclosed what exactly it is they do and what they want to do

[05:34:00.0000] <zcorpan_>
or wait, it doesn't yeald the same result. not preparsing doesn't catch encoding declarations in cdata elements

[05:34:01.0000] <zcorpan_>
so if it's optional and different how can we achieve interop?

[05:35:00.0000] <hsivonen>
/me would be interested in learning Hixie's thinking here

[05:36:00.0000] <hsivonen>
where does svn keep passwords? does the working copy have any private data?

[05:38:00.0000] <Philip`>
If you checked out from a http://name:password⊙. then it'll store that in .svn/entries, which (I've found) becomes annoying when you don't notice

[05:39:00.0000] <Philip`>
If you don't do that, I think it's up to the SVN client how it asks you for passwords or remembers the previous entries, and it shouldn't store that in the working copy anywhere

[05:40:00.0000] <Philip`>
(No idea where it does store it, though)

[05:40:01.0000] <annevk>
can you make it store it?

[05:40:02.0000] <hsivonen>
Philip`: thanks

[05:41:00.0000] <hsivonen>
I guess I'll sanitize the svn-specific directories then

[05:41:01.0000] <Philip`>
I guess it also depends if it's http:// vs svn+ssh://, since the SVN client will log in in different ways and would differ on whether/how it saves passwords

[05:42:00.0000] <hsivonen>
the Java http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#mark(int) contract doesn't allow saying that the mark should never become invalid...

[05:42:01.0000] <hsivonen>
which totally sucks considering arbitrary rewinding

[05:42:02.0000] <Philip`>
'svn export' seems to be a convenient way of removing the .svn directories

[05:43:00.0000] <hsivonen>
OTOH, if the underlying stream *does* support arbitrary rewinding, implementing my own is bad for perf

[05:44:00.0000] <hsivonen>
do browsers act on a meta charset even if there's a <body> first?

[06:58:00.0000] <hsivonen>
zcorpan_: one thing you could test is putting upper or lower case Turkish i in various places where the spec requires a literal string that contains an i

[06:59:00.0000] <hsivonen>
zcorpan_: Opera has a history of making comparisons where the Turkish i equals an ASCII i

[07:08:00.0000] <zcorpan_>
hsivonen: ok. thanks

[07:11:00.0000] <zcorpan_>
U+0130 (İ) and U+0131 (ı)

[08:54:00.0000] <zcorpan_>
why is Node.localName uppercased?

[08:56:00.0000] <annevk>
because there are people relying on it I guess?

[08:56:01.0000] <zcorpan_>
hmm... wouldn't think so

[08:57:00.0000] <annevk>
because it returns undefined in IE?

[08:58:00.0000] <zcorpan_>
yeah. and if you use .localName you probably also check .namespaceURI or so. and i wouldn't expect it to be uppercased

[09:00:00.0000] <annevk>
it would be nice if there was a canonical property available

[09:00:01.0000] <zcorpan_>
you might do something like if ((elm.tagName == "A" && !elm.namespaceURI) || (elm.localName == "a" && elm.namespaceURI == "http://www.w3.org/1999/xhtml"))

[09:01:00.0000] <zcorpan_>
where the former is for legacy HTML UA and the second is for HTML5 UA and for XHTML

[09:11:00.0000] <annevk>
hmm, document.createElementNS("A", xhtmlNS) is interesting

[09:11:01.0000] <annevk>
it will claim "a" yet not implement HTMLAnchorElement

[09:12:00.0000] <zcorpan_>
createElementNS is case-changing? in what impl?

[09:12:01.0000] <annevk>
the English prose of HTML5?

[09:12:02.0000] <annevk>
for HTML Elements (elements in the XHTML namespace) in HTML documents .tagName etc. will return lowercase

[09:13:00.0000] <annevk>
however, document.createElementNS will not have its first argument lowercased

[09:13:01.0000] <annevk>
which gives you the aforementioned edge case

[09:13:02.0000] <zcorpan_>
ah. ok. then createElementNS isn't case-changing (and html5 doesn't say it is)

[09:15:00.0000] <zcorpan_>
.tagName will return uppercase btw

[09:27:00.0000] <hsivonen>
zcorpan_: +1 on localName returning lower case in text/html DOM

[09:50:00.0000] <duryodhan>
isn't drawWindow part of the HTML5 specs?

[09:50:01.0000] <duryodhan>
(canvas)

[09:50:02.0000] <annevk>
no

[09:55:00.0000] <duryodhan>
so is it supported only by mozilla firefox?

[09:55:01.0000] <duryodhan>
or by opera/safari ?

[09:56:00.0000] <annevk>
I believe only by Firefox

[09:56:01.0000] <annevk>
and only for priveleged JavaScript

[10:07:00.0000] <Philip`>
duryodhan: Yep, it's Firefox-only (so it really should be in a getContext('moz-2d') or something, though it isn't, which is perhaps annoying if the spec added something like drawWindow (e.g. to handle the text-drawing issue) with different semantics)

[10:08:00.0000] <duryodhan>
text-drawing issue?

[10:09:00.0000] <Philip`>
You can't (currently) draw text onto the canvas easily, and I think one proposed solution was to have something like drawWindow so you could set up an HTML element with CSS formatting and everything, and stick text into that and then draw it onto the canvas

[10:11:00.0000] <duryodhan>
hmm ... then might as well implement the moz drawWindow ...

[10:13:00.0000] <Philip`>
Hmm, I guess it would have to be more like drawElement rather than drawWindow

[10:14:00.0000] <Philip`>
(or just another drawImage overload)

[10:15:00.0000] <Philip`>
since drawing whole windows is a fairly limited functionality (unless you're very careful and cut out precisely the section surrounding the element you want), so maybe it doesn't matter that they stole the drawWindow name already

[10:17:00.0000] <duryodhan>
the problem with drawElement would be ... it is painful to know where the element is exactly ...

[10:17:01.0000] <duryodhan>
mean to say a form ...

[10:17:02.0000] <duryodhan>
one could start off a form anywhere and end it anywhere ... 

[10:18:00.0000] <duryodhan>
the code for some buttons might be in between the <form > and </form>

[10:18:01.0000] <duryodhan>
but the button may be in some god forsaken place ...

[10:20:00.0000] <Philip`>
The form element is always defining a subtree in the DOM, so you can just do drawElement(getElementById('some-form'), 200, 100, 0, 0) and the browser can work out how to render that piece of the document (with all its contained elements, and affected by stylesheets) in a 200x100 container with a transparent background, then paint it onto the canvas at posiion 0,0, perhaps

[10:21:00.0000] <Philip`>
s/ii/iti/

[10:24:00.0000] <duryodhan>
so it will basically draw so that everything in between <form> </form> is rendered?

[10:27:00.0000] <Philip`>
Yep - kind of like extracting the whole <form>...</form> into a new clean document and rendering that, ignoring all the extra stuff from the original page (except probably keeping all the stylesheets that applied to that element (and its contents) from the original page). But maybe that's totally impossible to implement - I have no idea really :-)

[10:28:00.0000] <duryodhan>
yeah...

[10:28:01.0000] <duryodhan>
I was trying to do something like that in scripts ...

[10:28:02.0000] <duryodhan>
offsetLeft etc....

[10:29:00.0000] <duryodhan>
but I am pretty sure that the co-ords would be wrong for a weird form

[10:32:00.0000] <Philip`>
It does sound hard (/impossible) in general to work out what rectangle on the page corresponds to a certain element, particularly if there's stylesheets moving everything around

[10:33:00.0000] <Philip`>
and perhaps that would be simplified by just defining the rectangle first, and then telling the content to draw itself inside there (the same as what happens when drawing stuff into the screen rectangle, except directly onto the canvas rather than the screen)

[10:36:00.0000] <duryodhan>
I don't think I understand ... if the content is drawn into the canvas .. user can

[10:36:01.0000] <duryodhan>
't interface with it 

[10:39:00.0000] <Philip`>
Why would you want an interactive form in the canvas, rather than just drawn as normal HTML?

[10:45:00.0000] <duryodhan>
I mean to ask .... why would you directly write to canvas?

[10:45:01.0000] <duryodhan>
instead of writing to HTML ?

[10:45:02.0000] <duryodhan>
I dont know what I am talking

[10:45:03.0000] <duryodhan>
:)

[10:49:00.0000] <Philip`>
Oh, as in why would you draw the element as a new separate thingy onto the canvas, rather than cutting out an existing part of the rendered HTML page?

[10:49:01.0000] <Philip`>
Probably the main reason is that you'd want to draw things without them being part of the HTML page

[10:50:00.0000] <Philip`>
like drawElement(document.createTextNode('Hello world')) or something

[10:50:01.0000] <Philip`>
else you'd end up with loads of rubbish stuck all over your page, when you only ever wanted to draw it into the canvas

[10:58:00.0000] <duryodhan>
yeah.. I am still stuck with the notion of drawing stuff already existing on the page ....i.e clicking a snap ...

[10:58:01.0000] <duryodhan>
/me is a little confused and talking through his hat

[10:58:02.0000] <Philip`>
/me doesn't really know about the actual technical details about how any of this could work

[10:59:00.0000] <duryodhan>
hehe

[10:59:01.0000] <duryodhan>
two ppl who don't know anything ... discussing stuff ...

[11:00:00.0000] <Hixie>
hsivonen: the current spec on encoding was what it is now before you asked me if i was going to make any more changes, and the changes were made in response to your e-mail

[11:29:00.0000] <Hixie>
annevk: there are people discussing XHR in the whatwg list

[12:00:00.0000] <met_>
http://www.0x000000.com/?i=365

[12:29:00.0000] <gsnedders>
how do browsers deal with LF separated HTTP headers?

[12:52:00.0000] <hsivonen>
Hixie: yeah, that email was from the time when I thought that a single pass over the document and changing decoders on the fly was feasible. :-(

[13:09:00.0000] <Hixie>
hsivonen: i think what the spec does now is pretty much what is required for web compat. note that the 512 byte thing isn't wasted, it's actually still there it's just that you get to pick the number (and it can be zero or the whole file)

[13:09:01.0000] <Hixie>
(or anywhere in between, including 512)

[13:10:00.0000] <hsivonen>
Hixie: ok. I'll cool down a bit and implement the tree builder spec

[13:10:01.0000] <Hixie>
heh

[13:10:02.0000] <hsivonen>
(obviously, I should have paid closer attention to the sniffing section. I was tracking the changes to tokenization)

[13:11:00.0000] <Hixie>
well my point is there weren't really any changes

[13:11:01.0000] <Hixie>
just additions

[13:11:02.0000] <Hixie>
i don't think it should have made any code you wrote obsolete

[13:12:00.0000] <hsivonen>
Hixie: I think the main issue is if we can get browsers to agree how many bytes to examine. if not, everyone will have to scan the entire file or risk incompatibility with someone else

[13:12:01.0000] <Hixie>
no the current system is that you scan as many bytes as you like, and then do the real parser, and if the real parser finds a conflicting encoding, you start over using that instead.

[13:12:02.0000] <Hixie>
which is what browsers do, basically

[13:12:03.0000] <Hixie>
it makes the prescan optional for interop, effectively

[13:13:00.0000] <Hixie>
gotta go, lunch, brt

[13:13:01.0000] <Hixie>
bbl, rather

[13:13:02.0000] <hsivonen>
Hixie: another thing: since the sniffing can now proceed past the first 512 bytes, the perf penalty for not declaring the encoding is potentially serious. 

[13:13:03.0000] <hsivonen>
Hixie: so it would make sense to encourage even the ASCII-only folk to declare

[13:14:00.0000] <hsivonen>
Hixie: also, always making the undeclared case non-conforming helps sanity checking CMSs even if it is a tad drastic for individual docs

[13:30:00.0000] <Lachy>
this is cool http://iphonetester.com/

[13:52:00.0000] <hsivonen>
are head and body the only node that get attributes appended to them after the initial insertion to the document?

[14:01:00.0000] <mpt>
annevk, "misnormers" is a misnomer

[14:06:00.0000] <zcorpan_>
hmmm... now that i test again, ie seems to skip past CDATA and RCDATA elements when looking for encoding declarations

[14:07:00.0000] <zcorpan_>
or it uses its real parser, with the content model flags

[14:15:00.0000] <zcorpan_>
the problem with the current spec is that the preparser can find things that the real parser doesn't

[14:16:00.0000] <zcorpan_>
also, safari, firefox and opera don't change their mind after they've found an encoding decl with the preparser

[14:17:00.0000] <zcorpan_>
afaict

[14:20:00.0000] <zcorpan_>
i.e., ie does what the spec says but preparses 0 bytes. the others do what the spec says but preparses the whole thing and sets the confidence flag to certain when it has found a meta charset

[14:27:00.0000] <zcorpan_>
mpt: misspelled or wrongly used?

[14:28:00.0000] <zcorpan_>
(or both)

[14:28:01.0000] <mpt>
possibly both

[14:28:02.0000] <mpt>
The passive voice makes the statement unexplained, so it's difficult to tell

[14:31:00.0000] <zcorpan_>
iirc, the earlier draft said that results="" assumed a particular UI or something like that

[14:36:00.0000] <Hixie>
hsivonen: well, UAs are gonna have to work out what the right tradeoff is for the encoding detection (how long to prescan before just doing the heavy duty parse)

[14:37:00.0000] <hsivonen>
Hixie: what about interop?

[14:37:01.0000] <Hixie>
hsivonen: the preparse never sets a confident encoding

[14:37:02.0000] <Hixie>
hsivonen: you always verify the encoding with the real parser

[14:37:03.0000] <hsivonen>
oh

[14:38:00.0000] <zcorpan_>
Hixie: does the real parser undo tentative encoding information if it doesn't find any?

[14:38:01.0000] <zcorpan_>
Hixie: <style><meta charset=utf-8></style>

[14:39:00.0000] <Hixie>
ah, good point

[14:39:01.0000] <Hixie>
then again, it's already non-compliant to not have an encoding declaration if you're not using pure ascii

[14:40:00.0000] <zcorpan_>
being non-compliant doesn't make implementations interoperate ;)

[14:40:01.0000] <hsivonen>
Hixie: why isn't to not have an encoding declaration. Period.?

[14:41:00.0000] <hsivonen>
s/isn't to/isn't non-compliant to/

[14:41:01.0000] <met_>
Should html5 drag&drop model work across domains or only in the same domain? cannot find it in the spec

[14:43:00.0000] <Hixie>
hsivonen: because I don't want "<!DOCTYPE HTML><title>Hello</title><p>Hello" to be invalid.

[14:44:00.0000] <zcorpan_>
Hixie: if we want encoding detection to be interoperable, then i think we either should go the ie route (use the real parser for the whole file to find encoding information) or the firefox/opera/safari route (use the pre-parser for the whole file to find encoding information)

[14:45:00.0000] <Hixie>
i do not believe that firefox uses the pre-parser over the whole file

[14:45:01.0000] <Hixie>
that would imply they don't do incremental parsing, which is demonstrably false.

[14:46:00.0000] <zcorpan_>
it finds encoding declarations inside <style>, and it doesn't change its mind later on with encoding declarations that the real parser would find

[14:46:01.0000] <Hixie>
yeah, i think they should fix that

[14:50:00.0000] <hsivonen>
Hixie: you could make it valid by adding the UTF-8 BOM

[14:50:01.0000] <Hixie>
i can't easily type the UTF-8 BOM

[14:51:00.0000] <hsivonen>
Hixie: do I understand correctly that "reconstruct the active formatting elements" is a no-op if only character tokens have been processed since the last "reconstruct the active formatting elements"?

[14:51:01.0000] <Hixie>
i believe that to be the case, yes

[14:51:02.0000] <hsivonen>
Hixie: thanks

[14:51:03.0000] <zcorpan__>
ok. so the ie route then. with an optional preparse. but then the real parser needs to undo tentative encoding information when it doesn't find any. no?

[14:52:00.0000] <Hixie>
hsivonen: in fact you can always treat runs of non-whitespace character tokens and runs of whitespace character tokens as single tokens.

[14:52:01.0000] <Hixie>
(the same is not true for runs of whitespace and non-whitespace)

[14:52:02.0000] <Hixie>
zcorpan_: well, what would it "undo" it to?

[14:52:03.0000] <hsivonen>
Hixie: that's what I'm asking, yes. And "in body" I can treat them both as a single token, right?

[14:53:00.0000] <Hixie>
i believe that's what i do in my parser, yes

[14:53:01.0000] <hsivonen>
ok. I'll optimize the "in body" case

[14:55:00.0000] <zcorpan__>
Hixie: whatever it would have used if it didn't preparse

[14:56:00.0000] <Hixie>
it would have used some random guess

[14:57:00.0000] <zcorpan__>
yeah. fair enough

[14:58:00.0000] <Hixie>
i mean i see what you're saying, but i don't really see how you could check to see if a UA did "undo" it or not

[14:58:01.0000] <Hixie>
i don't really have a good solution to this

[14:59:00.0000] <Hixie>
we can't really limit how much you preparse, or require it to be a certain minimum, because that has big perf implications

[14:59:01.0000] <Hixie>
and browsers would just ignore us

[14:59:02.0000] <zcorpan__>
you can check by comparing with a test that doesn't have any encoding declaration

[15:00:00.0000] <zcorpan__>
however, i don't think there is content that relies on encoding declarations in (r)cdata elements applying, since ie doesn't see them

[15:00:01.0000] <Hixie>
well, the problem is you are allowed to pick a different default each time

[15:00:02.0000] <Hixie>
as you "learn"

[15:01:00.0000] <zcorpan__>
ah. yeah that's true

[15:03:00.0000] <hsivonen>
Hixie: under "in table" anything else you say "If the current node is a table, tbody, tfoot, thead, or tr element, then, whenever a node would be inserted into the current node, it must instead be inserted into the foster parent element." How can the current node be anything other than a table element?

[15:04:00.0000] <Hixie>
<table><i>

[15:04:01.0000] <Hixie>
at this point, the current element is an <i>

[15:04:02.0000] <Hixie>
but you're "in table"

[15:05:00.0000] <hsivonen>
I see

[15:05:01.0000] <hsivonen>
but I don't see the consequences

[15:06:00.0000] <Hixie>
consider <table><i>X</i>Y

[15:06:01.0000] <Hixie>
the <i> goes into the foster parent

[15:06:02.0000] <Hixie>
then the X goes into the <i>, because the <i> is the current node

[15:06:03.0000] <Hixie>
then you close the <i> with the </i>, so the current node is the <table> again

[15:06:04.0000] <Hixie>
so the Y goes into the foster parent

[15:06:05.0000] <hsivonen>
Hixie: but the foster parent is the table itself, right?

[15:07:00.0000] <Hixie>
no, the foster parent is the element the table is in

[15:07:01.0000] <hsivonen>
ooh

[15:07:02.0000] <Hixie>
assuming no dom mutations are going on

[15:07:03.0000] <Hixie>
so <div><br 1><table><p><br 2></table><br 3> results in  <div><br 1><p><br 2><table></table><br 3></div>

[15:08:00.0000] <hsivonen>
ok

[15:09:00.0000] <hsivonen>
basically, insertToFosterParent will throw in the streaming mode

[15:10:00.0000] <Hixie>
fwiw what i did was use a function pointer as my "append to tree" function, and most of the time it's just the straight forward add to tree, but when "in table" in points to a function that does the check

[15:10:01.0000] <Hixie>
that way you don't pay for the cost all the time

[15:11:00.0000] <Hixie>
yes, in streaming mode i don't have a solution for tables

[15:11:01.0000] <Hixie>
what i recommend is actually to buffer up all the content that would be appended before the table

[15:11:02.0000] <Hixie>
and then when you leave the table, fire a non-SAX event of everything you collected

[15:12:00.0000] <Hixie>
or just delay all those events til after the table

[15:12:01.0000] <Hixie>
so the content that normally would go before the table goes after it instead

[15:12:02.0000] <hsivonen>
Hixie: I didn't follow: what saving did the function pointer give?

[15:13:00.0000] <Hixie>
wherever i would have called appendChild(), instead dereferenced the function and called that instead

[15:13:01.0000] <Hixie>
so it's just a pointer dereference each time

[15:13:02.0000] <Hixie>
instead of being a comparison to the current node each time

[15:13:03.0000] <Hixie>
maybe it's not cheap to do that in java

[15:13:04.0000] <Hixie>
in the language i was using a function pointer is exactly as cheap as a function call

[15:14:00.0000] <Hixie>
since all functions are actually function pointers

[15:14:01.0000] <hsivonen>
I don't see why the pointer thing wouldn't be masked by other branches anyway

[15:14:02.0000] <Hixie>
how do you mean?

[15:15:00.0000] <hsivonen>
If I check for "in table", doesn't that mask the pointer issue

[15:15:01.0000] <Hixie>
where?

[15:15:02.0000] <hsivonen>
or did you implement each phase as a set of function pointers that you plug in?

[15:15:03.0000] <hsivonen>
like html5lib has a class for each phase

[15:15:04.0000] <Hixie>
i just have a massive set of nested switch() statements

[15:16:00.0000] <hsivonen>
me too

[15:16:01.0000] <Hixie>
my implementation is basically a literal implementation of the spec

[15:16:02.0000] <hsivonen>
are your tokens objects or callbacks?

[15:16:03.0000] <Hixie>
they're tuples, which is basically a struct (object)

[15:17:00.0000] <hsivonen>
my tokens are callbacks, so the code order of the tree builder goes against the grain of the spec, which sucks

[15:17:01.0000] <Hixie>
my tokeniser is a function that runs until it returns a token

[15:17:02.0000] <Hixie>
ah

[15:17:03.0000] <Hixie>
why did you do it that way?

[15:17:04.0000] <Hixie>
i think the ideal way of implementing the tokeniser is a generator function a la python's yield

[15:18:00.0000] <hsivonen>
Hixie: because the "emit a token" model mentally matched SAX

[15:18:01.0000] <hsivonen>
Hixie: does yield store the current continuation?

[15:18:02.0000] <Hixie>
yes

[15:18:03.0000] <Hixie>
i've never used it but it seems perfect for the input stream and the tokeniser

[15:19:00.0000] <hsivonen>
no luck with storing continuations in Java without doing it by blocking a thread

[15:19:01.0000] <Hixie>
yeah, same in sawzall

[15:19:02.0000] <Hixie>
except you have no threads :-)

[15:20:00.0000] <hsivonen>
Hixie: anyway, doing the tokenizer the way I've seen SAX parsers written was a perfect match for the spec

[15:20:01.0000] <Hixie>
cool

[15:20:02.0000] <Hixie>
sounds less than perfect for the tree part :-(

[15:20:03.0000] <hsivonen>
Hixie: but now I need to group tree building by token instead of by phase/mode

[15:20:04.0000] <Hixie>
ah

[15:20:05.0000] <Hixie>
makes sense

[15:20:06.0000] <hsivonen>
yeah

[15:20:07.0000] <Hixie>
i've seen other implementations of the tree part that work that way

[15:21:00.0000] <Hixie>
so it's certainly possible

[15:21:01.0000] <hsivonen>
I haven't seen anything impossible yet. the random access to the spec just sucks

[15:21:02.0000] <Hixie>
random access to the spec?

[15:21:03.0000] <Hixie>
oh you mean the way the spec doesn't match it?

[15:21:04.0000] <Hixie>
yeah

[15:22:00.0000] <hsivonen>
Hixie: having to seek the right piece of spec when I go over my code stubs instead of making a sequential pass over the spec

[15:22:01.0000] <Hixie>
yeah

[15:28:00.0000] <hsivonen>
Hixie: Do I understand correctly that <div>foo<table>bar baz</table></div> parses to <div>foobarbaz<table> </table></div>

[15:28:01.0000] <Hixie>
yes but that's a bug in the spec

[15:28:02.0000] <Hixie>
not sure what it should do yet

[15:28:03.0000] <Hixie>
in particular, <div>foo<table> bar</table></div> vs <div>foo<table> <tr><td></table></div> is a tough one

[15:29:00.0000] <hsivonen>
hmm. perhaps I make that part horrendously inefficient then

[15:29:01.0000] <hsivonen>
no point in optimizing something that will be discarded

[15:37:00.0000] <zcorpan>
Hixie: hmm. afaict, ie, opera and safari all put the text inside the table. firefox handles that case as equivalent to <div>foobar<table> </table></div>

[15:38:00.0000] <Hixie>
which case?

[15:38:01.0000] <zcorpan>
<div>foo<table> bar</table></div>

[15:40:00.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cdiv%3Efoo%3Ctable%3E%20bar%3C/table%3E%3C/div%3E

[15:41:00.0000] <Hixie>
anything that results in the text appearing but while inside the <table> is wrong

[15:41:01.0000] <Hixie>
since it isn't compatible with the css model

[15:43:00.0000] <Hixie>
looks like we might be able to get away with just setting a flag that saves whitespace

[15:43:01.0000] <Hixie>
and reset the flag when you hit a table-related element

[15:43:02.0000] <Hixie>
i.e. when you "clear the stack..."

[15:44:00.0000] <zcorpan>
yep

[15:44:01.0000] <zcorpan>
safari treats <div>foo<table> <tr></tr>bar</table></div> as <div>foobar<table> <tr></tr></table></div>

[15:45:00.0000] <zcorpan>
opera and ie seem to put the text inside the table somehow. in ie, text inside table is inside an element with the tag name ""

[15:46:00.0000] <Hixie>
IE creates "fake caption" elements

[15:46:01.0000] <Hixie>
i spoke to the ie guys about it

[15:46:02.0000] <zcorpan>
ah

[15:46:03.0000] <Hixie>
they're having all kinds of trouble implementing the css table model on top of their parsing model

[15:47:00.0000] <hsivonen>
Hixie: the CSS table model has to handle crazy XML and DOM modifications anyway, right?

[15:47:01.0000] <zcorpan>
wonder how opera deals with it, since it has text nodes as child of table in the dom afaict

[15:47:02.0000] <Hixie>
hsivonen: the problem is that css wraps cells around unexpected elements in the table

[15:47:03.0000] <Hixie>
hsivonen: whereas we want to move all the content to before the table

[15:55:00.0000] <hsivonen>
Hixie: Ok. I'm not well aware of the legacy requirements here

[16:46:00.0000] <hsivonen>
Hixie: I don't understand why space characters cause "Reconstruct the active formatting elements" in "after body".

[16:58:00.0000] <hsivonen>
Hixie: when you go from trailing end to main phase, what's the insertion mode gonna be? in body?


2007-06-30
[17:27:00.0000] <Hixie>
hsivonen: it doesn't change from whatever it used to be

[17:27:01.0000] <Hixie>
hsivonen: (spec says that somewhere)

[17:28:00.0000] <Hixie>
hsivonen: the space thing could be an oversight, spaces aren't very well handled

[17:42:00.0000] <hsivonen>
Hixie: ok. that means I have to store the mode from which I switch to trailing end :-(

[17:43:00.0000] <hsivonen>
btw, IBM says their experience with the ICU4J charset detector is that 6KB of text is needed 

[17:43:01.0000] <hsivonen>
seems like a lot compared to half a KB

[17:43:02.0000] <Hixie>
needed for what?

[17:44:00.0000] <hsivonen>
Hixie: to get a good confidence in statistic-based encoding guessing

[17:44:01.0000] <othermaciej>
statistics-based heuristics are a pretty different thing from prescanning for meta tags

[17:45:00.0000] <hsivonen>
yes, they are

[17:45:01.0000] <hsivonen>
if I can help it, I'd prefer to avoid scanning the entire doc either way

[17:46:00.0000] <hsivonen>
rounded up to memory pages, the IBM figure yields an 8 KB buffer

[17:46:01.0000] <Hixie>
hsivonen: seems reasonable. the spec leaves it open to whatever the UA wants.

[17:48:00.0000] <hsivonen>
still, my reading of Gecko source suggests that chardet is only run on the first buffer and the impression I got was that Gecko buffers were closer to half a K

[17:52:00.0000] <Hixie>
quite possible

[23:51:00.0000] <Hixie>
/me sends a +1 e-mail

[01:43:00.0000] <Lachy>
/me disagrees with Hixie's +1 mail

[01:45:00.0000] <Lachy>
Hixie, the problem isn't the case sensitivity, it's the conflict caused by having more than one way to declare namespaces, regardless of case sensitivity

[01:52:00.0000] <Hixie>
i was agreeing with the fact that there is no need to have multiple ways to declare prefixes being "active" in the same place

[01:55:00.0000] <webben>
re longdesc, it's striking that the Mozilla bug commentators consider accessibility extensions as fulfilling the accessibility needs associated with supported longdesc in the UI: https://bugzilla.mozilla.org/show_bug.cgi

[01:56:00.0000] <Hixie>
nn

[01:56:01.0000] <webben>
*with supporting

[01:56:02.0000] <webben>
if this is the view developers are taking, then we need to take a much broader view of what UAs support

[01:57:00.0000] <webben>
sorry: https://bugzilla.mozilla.org/show_bug.cgi?id=1996

[01:59:00.0000] <webben>
(I don't think such a holistic view of the UA ecosystem is unreasonable anyhow; but folks are sometimes dismissive of features currently requiring plugin/add-on support, which doesn't make any sense if mainstream development depends on such add-ons to provide end-user functionality

[02:34:00.0000] <hsivonen>
Hixie: can you explain how one might hit point 7. in the CDATA/RCDATA tree building: "If the next token is an end tag token with the same tag name as the start tag token, ignore it. Otherwise, this is a parse error."

[02:34:01.0000] <hsivonen>
can the parse error only be hit by scripting?

[03:06:00.0000] <hsivonen>
Hixie: I don't see the void elements that usually appear in head ever popped off the stack. They should all be accompanied by "Immediately pop the current node off the stack of open elements.", right?

[03:46:00.0000] <hsivonen>
Hixie: the reason why the CDATA/RCDATA is the way it is is to make script and style appending atomic from the scripting point of view, right? so I can greatly simplify things in a non-browser parser, right?

[05:40:00.0000] <hsivonen>
eww. the implicit </p> stuff is ugly

[05:48:00.0000] <annevk>
the tools will not generate </p>

[05:52:00.0000] <hsivonen>
the tools?

[05:52:01.0000] <annevk>
the tools that safe us

[05:52:02.0000] <hsivonen>
oh

[05:53:00.0000] <hsivonen>
annevk: anyway, I don't want the tree builder methods to call each other recursively to enable stack frame creation omission compiler optimizations

[05:54:00.0000] <annevk>
nice sentence

[05:54:01.0000] <hsivonen>
annevk: which means "acting as if" an end tag had been seen when I'm processing a start tag gets ugly

[05:55:00.0000] <annevk>
what is the big deal about creating a new token running that through the parser and then running the token you were processing again?

[05:56:00.0000] <hsivonen>
annevk: the "tokens" don't exist as objects

[05:56:01.0000] <hsivonen>
annevk: so doing that would mean calling the methods in a way that poisons the said compiler optimization

[05:58:00.0000] <annevk>
ah ok

[05:59:00.0000] <hsivonen>
this is of course moot if HotSpot doesn't do the said optimization but I remember reading that it does

[06:02:00.0000] <hsivonen>
this is one of those areas where I'm doing smart stuff if I guess the compiler behavior right and I'm doing stupid stuff if I guess wrong but verifying the guess takes more time than the wasted time caused by the guess being wrong

[06:46:00.0000] <annevk>
wow, check IE7 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cbody%3E%3Cobject%20src%3D%22image%22%20type%3D%22text/html%22%3E

[06:47:00.0000] <annevk>
if you use a src= attribute on <object> it generates some type of data URI inside the data attribute?!

[07:02:00.0000] <Philip`>
It does the same with <object type="text/html" data="data:">, as long as you have "data:" (case-insensitive) at the start, replacing it with its own weird URI

[07:06:00.0000] <Philip`>
IE6 (at least when in Wine) does about the same except its data: thing is the same first 16 bytes as in IE7, then a more complete document ("<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD><BODY><P>&nbsp;</P></BODY></HTML>")

[07:09:00.0000] <annevk>
it would be nice if there was a dom view for the rendered view too

[07:09:01.0000] <annevk>
oh

[07:09:02.0000] <annevk>
it has a refresh button

[07:09:03.0000] <annevk>
duh

[08:44:00.0000] <annevk>
heh, the PNG group rejected APNG

[08:44:01.0000] <annevk>
didn't know that

[08:45:00.0000] <annevk>
"Voting has closed on the APNG proposal. There were 8 YES votes, 10 NO votes, no abstentions, and no ineligble votes cast. The proposal has failed and the APNG chunks are not registered."

[08:48:00.0000] <Philip`>
http://blog.vlad1.com/archives/2007/04/26/143/ has some comments on that (including "maybe see about publishing it as an unofficial spec through the WHATWG (if there is interest in that group)", though I have no idea what more recent plans are like)

[08:49:00.0000] <annevk>
I wonder if other vendors are going to adopt it. Such as Internet Explorer...

[09:08:00.0000] <annevk>
http://gjuyn.xs4all.nl/pnganim.html is also interesting

[09:42:00.0000] <webben>
Any thoughts on why previous attempts to improve on <img> failed where new attempts to create <video> and <audio> object would succeed?

[09:43:00.0000] <annevk>
<video> and such are being implemented?

[09:44:00.0000] <annevk>
well, I guess more that people are used to <img>

[09:44:01.0000] <gsnedders>
and using <object> and the like can get overly complex trying to embed video

[09:45:00.0000] <annevk>
hmm, more people don't get <dl>

[09:46:00.0000] <annevk>
yeah, especially for APIs

[09:46:01.0000] <annevk>
got to go

[09:50:00.0000] <Philip`>
Maybe <img> is almost good enough already, so the cost of changing it outweighs the benefits of improving it, whereas <video>/<audio> can be improved much more by changing them

[09:51:00.0000] <webben>
i thought <image> /was/ implemented (same as <img>)

[09:51:01.0000] <webben>
what was the other attempt to replace img?

[09:52:00.0000] <webben>
I mean there's TBL's original suggestion: http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0106.html

[09:52:01.0000] <webben>
but that never made it into a spec AFAIK

[09:53:00.0000] <webben>
ah ... <fig> ? http://www.w3.org/MarkUp/html3/figures.html

[09:54:00.0000] <Philip`>
<image> wasn't an attempt to replace <img> - it was just an attempt to be nice to authors and error-correct their frequent misspellings of the tag name

[09:56:00.0000] <Philip`>
(...or at least I'm guessing that's what it was, and I'd be rather surprised if that wasn't true)

[09:58:00.0000] <gsnedders>
Philip`: that is true

[09:58:01.0000] <webben>
hmm <fig> works at least as well as the <pic> and <picture> varieties being proposed

[09:58:02.0000] <gsnedders>
Philip`: now my speculation: bug reports to browsers about <image> not working

[09:58:03.0000] <webben>
(at least judging by IE6 and Fx2) ... just doesn't display the image

[09:58:04.0000] <gsnedders>
webben: all seem to define specific types of image

[09:59:00.0000] <webben>
gsnedders: all what?

[09:59:01.0000] <webben>
<fig> seems to be generic

[09:59:02.0000] <gsnedders>
webben: picture, figure, etc.

[09:59:03.0000] <webben>
i think picture is intended to be generic too

[09:59:04.0000] <webben>
(from what I've seen of public-html proposals)

[09:59:05.0000] <gsnedders>
is a diagram stored in an image a picture?

[09:59:06.0000] <webben>
yes

[10:00:00.0000] <gsnedders>
yes, but the name suggests otherwise

[10:00:01.0000] <webben>
no

[10:00:02.0000] <webben>
it doesn't actually

[10:00:03.0000] <gsnedders>
(and I know the name of the element is irrelevant for semantics)

[10:00:04.0000] <webben>
no i mean "picture" is not a word that excludes "diagram"

[10:00:05.0000] <webben>
(or photo, or painting, or whatever)

[10:01:00.0000] <webben>
"I took a picture" , "I painted a picture" ...

[10:01:01.0000] <gsnedders>
in my head a diagram isn't a picture.

[10:03:00.0000] <webben>
http://www.google.co.uk/search?hl=en&q=define%3Apicture

[10:03:01.0000] <webben>
i think your head is wrong on this one ;)

[10:04:00.0000] <webben>
i agree that picture has some connotation of likeness vs abstraction

[10:04:01.0000] <webben>
but an abstract painting would still be a picture in common parlance

[10:04:02.0000] <webben>
so even that doesn't really hold up

[10:05:00.0000] <webben>
i think image actually excludes the idea of diagram more than picture does

[10:05:01.0000] <webben>
because an image actually means "copy"

[10:05:02.0000] <webben>
http://www.etymonline.com/index.php?term=image

[10:06:00.0000] <webben>
whereas picture ultimately refers to the act of painting

[10:06:01.0000] <webben>
http://www.etymonline.com/index.php?term=picture

[10:12:00.0000] <Philip`>
"figure" is generic enough that it usually includes tables as well as images, at least in TeX-like documents

[10:16:00.0000] <webben>
Philip`: yes figure is probably too generic ... although HTML5's figure seems intended to be used mainly for non-textual materials

[10:28:00.0000] <webben>
http://lists.w3.org/Archives/Public/public-html/2007Jun/1083.html doesn't make sense as a reason for <embed> not having alt since current UAs to have some support for alt on embed

[10:28:01.0000] <webben>
(as it sort of admits)

[10:35:00.0000] <Philip`>
Maybe <embed alt> is missing just because it's not specified anywhere and nobody thought of it when adding embed in HTML5?

[10:36:00.0000] <Philip`>
(Or maybe people are much more aware of such things than I am :-) )

[10:41:00.0000] <Philip`>
Hmm... As far I can tell, Lynx and Opera show the embed's alt; Links and Firefox and IE and Safari don't

[10:48:00.0000] <zcorpan>
there is <noembed>... but if you need fallback use <object>

[10:49:00.0000] <Hixie>
hsivonen: the void elements aren't actually put on the stack.

[10:49:01.0000] <Hixie>
hsivonen: the CDATA/RCDATA stuff could hit an EOF token

[10:52:00.0000] <Philip`>
(w3m doesn't show the embed alt either)

[10:54:00.0000] <zcorpan>
Philip`: you have a test case for embed alt?

[10:55:00.0000] <Philip`>
data:text/html,<embed alt="alt">

[10:55:01.0000] <Philip`>
That's about what I was testing :-)

[10:55:02.0000] <zcorpan>
Philip`: doesn't show anything in opera for me

[10:56:00.0000] <Philip`>
Oops... Try <embed alt="alt" src="404">

[10:56:01.0000] <zcorpan>
ah. o9.5 shows it indeed

[10:57:00.0000] <Philip`>
(Half my tests were wrong, then...)

[10:57:01.0000] <webben>
Philip`: Have you checked Firefox and IE with the Microsoft's accessibility inspector (I haven't as yet)

[10:57:02.0000] <zcorpan>
and lynx

[10:57:03.0000] <webben>
IIRC HTML5 keeps <embed> for Flash

[10:57:04.0000] <Philip`>
Lynx shows the alt text, Links shows a "[EMBED]" link, w3m shows a "embed(404)" link

[10:58:00.0000] <webben>
zcorpan: in which case one use-case would be http://www.rnib.org.uk/wacblog/news/just-how-accessible-is-the-web-bbc-1s-click-investigates/

[10:58:01.0000] <Philip`>
(IE and Safari still don't show any alt text, just a broken image icon (in IE) or a blank space (in Safari))

[10:58:02.0000] <webben>
it's embedded in a discussion of why using invalid HTML can have unpredictable effects on accessibility

[10:58:03.0000] <Philip`>
(regardless of whether src is specified or not)

[10:59:00.0000] <webben>
Philip`: some of those text browsers can be quite configurable.

[10:59:01.0000] <webben>
Philip`: so that's not necessarily their only possible response

[10:59:02.0000] <Philip`>
webben: I haven't checked it with that (and I can't entirely easily, since rdesktop keeps crashing at random times when I try connecting to Windows...)

[11:00:00.0000] <webben>
Philip`: Fair enough. :)

[11:00:01.0000] <Philip`>
((I blame my video drivers rather than rdesktop for that, since it used to work fine))

[11:00:02.0000] <webben>
I think the main advantage is for Lynx though.

[11:01:00.0000] <webben>
in particular you can do <embed alt="">

[11:01:01.0000] <webben>
(which in the particular use-case cited would have helped)

[11:04:00.0000] <webben>
Philip`: is your testcase online?

[11:05:00.0000] <Philip`>
No, but I could upload something quickly if it'd be useful

[11:05:01.0000] <webben>
Philip`: I suppose I can make one myself; no reason to trouble you unless you'd already done it :)

[11:09:00.0000] <Philip`>
Oh, Links is slightly odd

[11:09:01.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/embedalt.html

[11:09:02.0000] <Philip`>
Links shows the alt text when you embed an image, but not when you embed something that doesn't exist

[11:10:00.0000] <Philip`>
Also, Opera doesn't like embedded images at all, since it wants me to install a plugin

[11:16:00.0000] <webben>
I'm using .swf as an extension in my test

[11:16:01.0000] <webben>
since AFAICT that's the only reason to use embed

[11:17:00.0000] <Philip`>
That's probably sensible

[11:17:01.0000] <Philip`>
/me doesn't have any easily-available .swf files

[11:19:00.0000] <webben>
oh ... i was just testing with a non-existent one

[11:19:01.0000] <Philip`>
Ah, I can steal the Live DOM Viewer's Flash file...

[11:19:02.0000] <webben>
http://www.benjaminhawkeslewis.com/www/test-cases/embed-alt.html

[11:19:03.0000] <webben>
maybe i need both

[11:19:04.0000] <Philip`>
http://canvex.lazyilluminati.com/misc/embedalt.html - now with a .swf

[11:20:00.0000] <Philip`>
Links shows [EMBED] for pass.swf and 404, and shows the alt text (or an empty space) for green.png

[11:21:00.0000] <Philip`>
(Lynx still always shows the alt text (or [EMBED] if there is none))

[11:22:00.0000] <webben>
could you add one with a .swf extension that 404s

[11:22:01.0000] <webben>
it's possible UAs might react different for that

[11:22:02.0000] <Philip`>
Done

[11:22:03.0000] <webben>
cool :)

[11:23:00.0000] <Philip`>
Opera does act differently based on the extension; I can't see anything else that does

[11:24:00.0000] <Philip`>
(though I don't have Flash installed in any browser other than Opera)

[12:30:00.0000] <hsivonen>
Hixie: e.g. img is put on the stack and immediately popped. e.g. link is put on the stack and never popped (I pop it on my own)

[16:09:00.0000] <Hixie>
hsivonen: oh yeah, never noticed that. huh. send mail?