00:02:45 <karl> karl has joined #html-wg
00:23:11 <mjs> mjs has joined #html-wg
00:29:05 <MikeSmith> MikeSmith has joined #html-wg
00:49:46 <gavin_> gavin_ has joined #html-wg
01:02:34 <aroben_> aroben_ has joined #html-wg
01:15:39 <kingryan> kingryan has joined #html-wg
01:16:49 <kingryan> kingryan has joined #html-wg
01:40:40 <aroben> aroben has joined #html-wg
02:39:56 <karl> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0170.html
02:40:01 <karl> Using webservices for RDFa test suite validation
02:40:13 <karl> The new tool, crazyivan.py[1], will do the following:
02:40:13 <karl>  - Retrieve all approved or unreviewed RDFa test cases from the W3C.
02:40:13 <karl>  - Use the pyRDFa Distiller web service[2] to convert to RDF and run a
02:40:13 <karl>    modified SPARQL query from the test suite using the sparqler
02:40:13 <karl>    interface[3].
02:40:14 <karl>  - Dump the XHTML, N3 triples, RDF, and SPARQL to separate files.
02:40:18 <karl>  - Generate a test report, containing all the information necessary
02:40:20 <karl>    (XHTML, N3, RDF, and SPARQL), to understand the test case.
02:46:17 <karl> http://www.ilinsky.com/articles/XMLHttpRequest/
02:46:23 <karl> Re-inventing XMLHttpRequest: Cross-browser implementation with sniffing capabilities
02:56:49 <gavin_> gavin_ has joined #html-wg
03:26:28 <polin8> polin8 has joined #html-wg
03:48:58 <olivier> olivier has joined #html-wg
04:02:17 <Zeros> Zeros has joined #html-wg
05:04:43 <gavin_> gavin_ has joined #html-wg
05:08:05 <mjs> mjs has joined #html-wg
06:15:45 <polin8> polin8 has joined #html-wg
06:17:55 <polin8> polin8 has joined #html-wg
06:45:23 <aroben> aroben has joined #html-wg
06:51:27 <MikeSmith> MikeSmith has joined #html-wg
06:57:37 <laplink> laplink has joined #html-wg
07:11:40 <gavin_> gavin_ has joined #html-wg
07:28:55 <tH_> tH_ has joined #html-wg
08:04:53 <Lachy> Lachy has joined #html-wg
08:35:17 <MikeSmith> MikeSmith has joined #html-wg
08:38:04 <John_Boyer> John_Boyer has joined #html-wg
08:38:36 <John_Boyer> John_Boyer has left #html-wg
08:51:17 <Lachy> Lachy has joined #html-wg
09:03:46 <zcorpan> zcorpan has joined #html-wg
09:05:33 <ROBOd> ROBOd has joined #html-wg
09:17:41 <Lachy> Lachy has joined #html-wg
09:18:58 <gavin_> gavin_ has joined #html-wg
09:48:35 <anne> http://www.schepers.cc/?p=46
09:49:17 <Steve_f> Steve_f has joined #html-wg
09:52:31 <beowulf> the use of the word 'spastic' in that article should be reconsidered
09:53:38 <beowulf> http://en.wikipedia.org/wiki/Spastic # 2nd para, UK context
09:54:35 <anne> he's from the US though
09:54:57 <beowulf> i know, but it'll likely create something
09:56:42 <anne> I'ts unclear why he assumes that "Aria 2" would be backwards incompatible and why he assumes there will be many new languages like "Aria" that require a similar extension mechanism
09:57:42 <anne> But maybe that's what you do at the W3C. Generalize solutions so you can place your solution within a framework...
09:58:16 <Dashiva> beowulf: If people want to misunderstand, I'm sure they'll find a way regardless
10:03:42 <Lachy> I'm not thrilled about the idea of using prefix_foo for namespaces, especially for tag names, mostly because of backwards compatibility
10:04:55 <Lachy> but I suppose reserving prefixes and continuing to use the colon would be even less backwards compatible
10:06:11 <Hixie> we could use a hyphen...
10:06:51 <Lachy> what about a semi-colon? Would that still be well-formed?
10:07:20 <Lachy> sadly, no :-(
10:07:21 <Hixie> <foo aria;disabled=""> looks retarded
10:07:31 <Lachy> yeah, but it's easier to type than an underscore
10:07:31 <Hixie> seriously, what's wrong with aria-disabled?
10:07:49 <Hixie> other than some nonsense argument about "generic prefix mechanisms"
10:10:17 <Lachy> I don't have a problem with aria-*, but I don't see how we could get them to stop trying to make it completely generic
10:10:55 <Hixie> why try?
10:11:01 <Hixie> (and who is "them"?)
10:11:42 <Lachy> whoever it is that argued for making this a generic prefix mechanism and came up with the idea of using underscore
10:12:13 <Hixie> my understanding is that that was doug
10:12:24 <Hixie> and i would not stop him making it generic if he wants to
10:12:41 <Hixie> though my understanding is that merely using a hyphen is enough to stop him making it generic
10:12:58 <Hixie> since he said the reason to _not_ use a hyphen was that you _couldn't_ make it generic with a hyphen
10:15:11 <Lachy> oh, I still don't think aria is useful, but continuing to argue about that doesn't seem all that productive and I've got better things to do
10:16:16 <Hixie> like argue about the syntax? :-D
10:16:48 <Lachy> :-)
10:26:53 <gsnedders> oh, can we have a @land in case I misspell @lang again? (see, I gave my use case!)
10:26:56 <anne> Hixie, are you already below 5000 outstanding e-mails or are they coming in at about the same rate as you address them? :)
10:27:27 <Hixie> i'm at 3712
10:27:35 <anne> cool
10:27:39 <Hixie> (as of 4am last night)
10:28:09 <anne> you make strange days, trying to accomedate us? :p
10:29:22 <Hixie> it's when i'm not likely to be editing the imap folders :-)
10:29:26 <Hixie> http://www.whatwg.org/issues/data.csv
10:29:38 <Hixie> third column is the number that matters
10:29:46 <Hixie> don't ask me what timezone that's in, btw
10:29:50 <Hixie> i have no idea
10:29:55 <Hixie> probably UTC but i'm not sure
10:31:06 <Philip> Oops, I forgot it takes forever for public-html emails to appear when you use a new address
10:34:42 <Hixie> interesting numbers
10:34:51 <Hixie> well i should sleep
10:34:53 <Hixie> nn all
10:39:02 <hsivonen> hmm. so I'm a Capulet and a Young Turk
10:45:29 <myakura> myakura has joined #html-wg
10:48:11 <Philip> "a parser is a program that reads a formal syntax and makes a model of it for the browser to act on" - that sounds slightly inaccurate, since it would exclude parsers for languages with no formal syntax, like C++ (where some of the parsing requirements are defined by prose) or HTML5 (where nothing is formal) or Perl (where the parsing isn't defined at all)
10:50:07 <marcos> philip, iit's a blog entry, not a spec ;) 
10:52:13 <gsnedders> Philip: XML has some sort of BNF, does it not? SGML is just prose, though
10:53:41 <Philip> marcos: Indeed, it's not a real problem, I'm just being pedantic and/or thinking aloud :-)
10:54:17 <gsnedders> anne: Unicode 5.0 has very few requires regarding what exactly must be done on an error
10:54:31 <gsnedders> anne: also, earlier versions allowed five/six byte sequences
10:55:32 <Philip> gsnedders: Does the XML spec define enough stuff formally that you could feed it into a parser-creating tool and have a correct XML parser pop out?
10:56:13 <gsnedders> Philip: I think so. I've never tried, though.
10:58:25 <anne> no
10:59:12 <anne> most definitely not
11:01:43 <anne> gsnedders, yeah, I know; this all kind of sucks
11:02:14 <gsnedders> anne: did you hear in #whatwg about me having written a UTF-8 decoder?
11:02:44 <anne> no, what language?
11:02:47 <gsnedders> PHP
11:02:57 <anne> is it online somewhere?
11:03:18 <gsnedders> I'm hacking together some sort of unicode support for PHP < 6 (and it just uses the native stuff on PHP6)
11:04:21 <gsnedders> anne: http://pastebin.ca/740956
11:04:36 <gsnedders> anne: see line 200 onwards
11:07:50 <gsnedders> Anyone know what feed readers change their subscription upon receiving a permanent redirect?
11:07:56 <anne> your error handling seems pretty straightforward
11:08:06 <anne> most do, I think
11:11:55 <gsnedders> anne: I think it follows most of the recommendations in Unicode 5.0
11:12:52 <Philip> Was <ul aria.checked="true"> suggested for namespace-like syntax? That looks less ugly to me than _
11:13:45 <anne> no, but that looks like scripting to me
11:13:49 <anne> I think we should just use -
11:15:28 <gsnedders> -++
11:21:48 <hsivonen> I just sent email trying to say what I thought I said repeatedly on the telecon :-(
11:22:36 <paullewis> paullewis has joined #html-wg
11:26:19 <gavin_> gavin_ has joined #html-wg
11:26:38 <zcorpan> "The browser vendors have done *nothing* for a decade" ?
11:27:03 <zcorpan> --http://www.w3.org/mid/a707f8300710171329g305645c7wee83abcf99ecd130@mail.gmail.com
11:27:26 <anne> yeah... he's been arguing that point for quite some time
11:27:43 <anne> I think it has to do with us not implementing XForms
11:28:17 <zcorpan> so if you don't implement xforms, you're not doing anything?
11:28:37 <anne> I'm not sure what the reasoning is
11:36:01 <hsivonen> I guess that thread has gone beyond the point where participating would be productive
11:51:04 <karl> karl has joined #html-wg
11:56:49 <Philip> I guess ARIA attributes won't be reflected in the DOM, so element.aria_foo vs element['aria-foo'] isn't relevant?
11:57:01 <zcorpan> Philip: right
11:57:20 <zcorpan> just setAttribute()
11:59:00 <zcorpan> even if they were, the convention is to remove the hyphen and uppercase the next character
12:29:05 <timbl> timbl has joined #html-wg
12:37:08 <gsnedders> anne: Apache treats method names in the <Limit> directive as case-sensitive
12:37:54 <anne> this is in response to?
12:38:10 <anne> any idea how I can configure Apache btw to let through custom methods?
12:38:19 <gsnedders> anne: mainly just your prior research looking at such things a few days ago
12:38:53 <anne> k, makes sense that they do as method names are case-sensitive per HTTP
12:39:10 <anne> though browsers make a mess of that with XMLHttpRequest, but that helps authors too on the other hand
12:39:39 <anne> In HTML <form method=geT> is also not a geT request but a GET
12:40:57 <anne> oh fun, HTML4 says otherwise: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.1
12:41:13 <anne> 'get: With the HTTP "get" method'
12:41:20 <anne> ai ai ai
12:41:51 <gsnedders> anne: <http://hg.gsnedders.com/cgi-bin/hgwebdir.cgi/Unicode/> if you want a more perm IRI for my Unicode stuff
13:05:41 <Hixie> Hixie has joined #html-wg
13:29:43 <olivier> olivier has joined #html-wg
13:33:16 <gavin_> gavin_ has joined #html-wg
13:35:37 <matt> matt has joined #html-wg
13:37:22 <Sander> Sander has joined #html-wg
13:43:10 <polin8> polin8 has joined #html-wg
13:46:44 <xover> xover has joined #html-wg
13:57:25 <Lachy_> Lachy_ has joined #html-wg
13:58:00 <Lachy> Lachy has joined #html-wg
14:17:16 <aaronlev> aaronlev has joined #html-wg
14:49:53 <billmason> billmason has joined #html-wg
15:40:14 <gavin_> gavin_ has joined #html-wg
15:49:45 <Julian> Julian has joined #html-wg
15:55:57 <aaronlev> aaronlev has joined #html-wg
15:55:57 <Bob_le_Pointu> Bob_le_Pointu has joined #html-wg
15:57:22 <DanC> RRSAgent, bye
15:57:22 <RRSAgent> I see no action items
15:57:26 <RRSAgent> RRSAgent has joined #html-wg
15:57:26 <RRSAgent> logging to http://www.w3.org/2007/10/18-html-wg-irc
15:57:33 <Zakim> Zakim has joined #html-wg
15:57:36 <DanC> Zakim, this will be html
15:57:36 <Zakim> ok, DanC, I see HTML_WG()12:00PM already started
15:57:54 <Zakim> +DanC
15:57:59 <hsivonen> that's me
15:58:13 <DanC> Zakim, ??P3 is hsivonen 
15:58:13 <Zakim> +hsivonen; got it
15:58:30 <DanC> agenda + Convene HTML WG  meeting of 2007-10-18T16:00:00Z
15:58:43 <DanC> agenda + toward release of Design Principles
15:58:56 <DanC> agenda + Detailed Spec Reviews, toward 1st public WD of design
15:58:58 <oedipus> oedipus has joined #html-wg
15:59:05 <DanC> agenda + ARIAIntegration
15:59:15 <DanC> agenda + Name for XHTML serialization
15:59:26 <DanC> agenda + face-to-face meeting 8-10 November (short presentations?)
15:59:58 <DanC> Agenda: http://lists.w3.org/Archives/Public/public-html-wg-announce/2007OctDec/0003.html
16:00:18 <Zakim> + +49.251.2.aaaa
16:00:30 <DanC> -> http://www.w3.org/2007/10/11-html-wg-minutes minutes HTML WG 11 Oct
16:00:38 <DanC> Zakim, aaaa is JulianR
16:00:38 <Zakim> +JulianR; got it
16:02:27 <Zakim> +Gregory_Rosmiata
16:02:56 <DanC> JR: regrets for the ftf
16:03:37 <hsivonen> anne said he is "likely not" to be here http://krijnhoetmer.nl/irc-logs/html-wg/20071017#l-257
16:03:59 <DanC> oh.
16:04:40 <DanC> agenda + Issue Tracking
16:07:12 <DanC> next meeting: 25 Oct at 4p PT/23:00UTC, Chris W to chair
16:07:14 <oedipus> zakim, mute me
16:07:14 <Zakim> sorry, oedipus, I do not know which phone connection belongs to you
16:07:21 <DanC> Zakim, close item 1
16:07:21 <Zakim> agendum 1, Convene HTML WG  meeting of 2007-10-18T16:00:00Z, closed
16:07:22 <Zakim> I see 6 items remaining on the agenda; the next one is
16:07:23 <Zakim> 2. toward release of Design Principles [from DanC]
16:07:24 <DanC> Zakim, take up item Issue
16:07:24 <Zakim> agendum 7. "Issue Tracking" taken up [from DanC]
16:07:28 <oedipus> zakim, Gregory_Rosmiata is Gregory_Rosmaita
16:07:28 <Zakim> +Gregory_Rosmaita; got it
16:07:34 <DanC> JR: how about tracker, as used by TAG?
16:07:37 <oedipus> zakim, mute Gregory_Rosmaita
16:07:37 <Zakim> Gregory_Rosmaita should now be muted
16:07:50 <DanC> HS: keep in mind the WHATWG issue tracker that Ian H. uses
16:07:51 <DanC> (pointer)
16:08:19 <hsivonen> http://www.whatwg.org/issues/
16:08:55 <oedipus> Zakim, unmute me
16:08:55 <Zakim> sorry, oedipus, I do not know which phone connection belongs to you
16:09:01 <oedipus> Zakim, unmute Gregory_Rosmaita
16:09:01 <Zakim> Gregory_Rosmaita should no longer be muted
16:09:02 <DanC> DanC: what happens when hixie is done with an issue?
16:09:06 <hsivonen> http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/
16:09:11 <DanC> HS: it goes in the commit log
16:09:20 <hsivonen> that's a better view to the same tracker
16:09:38 <oedipus> zakim, mute Gregory_Rosmaita
16:09:38 <Zakim> Gregory_Rosmaita should now be muted
16:10:04 <DanC> DanC: do the names like "graphics-captions" show up in the commit logs?
16:10:22 <DanC> HS: not necessarily; this is a sanitized view of his IMAP status
16:11:18 <DanC> HS: the lazy... address has more persistent issue URIs
16:12:28 <DanC> DanC: the W3C tracker only recently keeps a good audit trail
16:13:04 <aroben> aroben has joined #html-wg
16:14:11 <DanC> DanC: I'm now comfortable using tracker...
16:14:44 <DanC> ... we could bulk load hixies list, or some combination of review and bulk load...
16:14:47 <Philip> (The lazy... one doesn't attempt to persist issues after they've been resolved (hence deleted from the IMAP view), and I think it only keeps cached copies for a day)
16:15:22 <DanC> http://www.w3.org/2002/09/wbs/40318/tasks83/results#xtasks
16:15:53 <DanC> [[
16:15:53 <DanC> issue tracking, summarization, and clustering 	
16:15:53 <DanC>     * Dan Connolly
16:15:53 <DanC>     * Chasen Le Hara
16:15:53 <DanC>     * Debi Orton
16:15:54 <DanC>     * David Dailey
16:15:56 <DanC>     * David McClure
16:15:58 <DanC>     * James Graham
16:16:00 <DanC>     * Ian Hickson
16:16:02 <DanC>     * Chris Adams
16:16:04 <DanC>     * Roman Kitainik
16:16:08 <DanC>     * Laura Carlson
16:16:10 <DanC>     * Benjamin Hedrington
16:16:12 <DanC>     * Karl Dubost
16:16:14 <DanC>     * Jens Meiert
16:16:16 <DanC>     * Shawn Medero
16:16:18 <DanC>     * Ben Millard
16:16:20 <DanC>     * Stephen Axthelm
16:16:22 <DanC>     * Eric Daspet
16:16:24 <DanC>     * Julian Reschke
16:16:26 <DanC> ]]
16:17:25 <DanC> -> http://blog.whatwg.org/html5lib-010-released html5lib 0.10 Released October 9th, 2007 by jgraham
16:17:43 <DanC> jgraham, you around?
16:18:34 <oedipus> zakim, unmute Gregory_Rosmaita
16:18:34 <Zakim> Gregory_Rosmaita should no longer be muted
16:19:19 <DanC> [[
16:19:20 <DanC> Ben Millard 	Professional content developer (HTML, CSS, accessibility).
16:19:20 <DanC> Provides standards- and browser-compliant solutions to markup problems raised on internet forums.
16:19:20 <DanC> Reads about accessibility, usability, standards and browser conformance.
16:19:21 <DanC> ]]
16:20:03 <DanC> ACTION: GR contact Ben Millard about regular issue triage
16:20:42 <DanC> JR: yes, with a team of people like that, I'd be willing to chime in regularly
16:21:14 <oedipus> zakim, mute Gregory_Rosmaita
16:21:14 <Zakim> Gregory_Rosmaita should now be muted
16:21:23 <DanC> http://www.w3.org/2001/tag/group/track/
16:21:41 <DanC> http://www.w3.org/2001/tag/group/track/issues/open
16:22:08 <DanC> what features in particular do you like from bugzilla, oedipus ?
16:22:39 <krijnh> krijnh has joined #html-wg
16:22:39 <DanC> HS: email integration is important; tracker takes email input?
16:22:45 <oedipus> annotation, linking to other issues, -- basically the details that usually otherwise fall between the cracks
16:22:52 <DanC> DanC: yes, it picks up ISSUE-NN mail
16:23:49 <oedipus> PF has been invoking trackbot-ng to track issues during telecons
16:25:03 <oedipus> since i'm a member of the forms task force, perhaps i should participate in forms-issues tracking and triage
16:25:41 <DanC> good point, oedipus 
16:25:43 <oedipus> it might give things a jump-start
16:25:51 <oedipus> yes
16:26:03 <DanC> ACTION DanC: request tracker installation for HTML WG
16:26:10 <DanC> Zakim, close this item
16:26:10 <Zakim> agendum 7 closed
16:26:11 <Zakim> I see 5 items remaining on the agenda; the next one is
16:26:12 <Zakim> 2. toward release of Design Principles [from DanC]
16:26:16 <DanC> Zakim, next item
16:26:16 <Zakim> agendum 2. "toward release of Design Principles" taken up [from DanC]
16:26:20 <oedipus> joint forms task force going to need to use issue tracker anyway...
16:26:39 <DanC> Sep 26 15:59:12 <mjs>	DanC: at some point I'd suggest to ship it instead of waiting more
16:26:39 <DanC> Sep 26 16:00:18 <DanC>	I'm ready to (propose to) ship when you are.
16:27:14 <DanC> we chatted a bit since then; ETA was 15 Oct at that point
16:27:24 <oedipus> last HDP document still datestamped 14 september 2007
16:27:47 <oedipus> there's been a fair bit of dialog on it since then
16:27:56 <DanC> ooh! 1.9 $ of $Date: 2007-09-14 09:44:18  is news to me. http://dev.w3.org/html5/html-design-principles/Overview.html
16:27:59 <oedipus> on public-html
16:28:07 <DanC> where has the dialog been? I haven't seen any [HDP] mail
16:28:14 <oedipus> not all of it
16:28:55 <hober> hober has joined #html-wg
16:29:05 <DanC> "accessibility" doesn't occur in 1.9
16:29:16 <oedipus> there is a lonely query from DanC about HDP status (10 october 2007)
16:29:17 <oedipus> http://lists.w3.org/Archives/Public/public-html/2007Oct/0124.html
16:29:39 <DanC> oh... 1.9 is not so new after all
16:30:05 <DanC> DanC: GR, what do you think about publishing 1.9?
16:30:11 <oedipus> no, there hasn't been any changes -- concerned that doesn't mention accessibility support for legacy 
16:30:21 <DanC> so we should wait for mjs to get to that bit
16:30:36 <oedipus> i18n, a11y and DI specific markup should be continued to be supported
16:30:41 <DanC> ACTION: Maciej to finish editng pass based on pending comments, e.g. from survey of 2007-08-16 to 2007-08-23 [CONTINUES]
16:31:03 <DanC> is there specific suggested text that you like re  i18n, a11y and DI ?
16:31:29 <oedipus> yes, i've submitted it to mjs on-list (public-html) at least thrice -- and once in a telecon
16:31:34 <DanC> pointer?
16:32:34 <oedipus> "Browsers should retain support for residual/legacy markup designed for 
16:32:34 <oedipus> a specific purpose, such as accessibility. internationalization or device 
16:32:34 <oedipus> independence. Simply because new technologies and superior mechanisms 
16:32:34 <oedipus> have been identified, not all of them have been implemented. Moreover, 
16:32:34 <oedipus> disabled users are more likely to be users of "legacy technology" because
16:32:35 <oedipus> it is the only technology that interacts correctly with third-party 
16:32:37 <oedipus> assistive technologies."
16:32:40 <oedipus> http://lists.w3.org/Archives/Public/public-html/2007Sep/0519.html
16:32:43 <DanC> tx
16:32:47 <oedipus> np
16:34:48 <oedipus> HenriS: note that this isn't the "marketplace" speaking, it is a constituency that is at the mercy of implementors and support for some of the features in UAs
16:34:52 <DanC> HS: not sure I like that for [reasons scribe missed]
16:35:28 <oedipus> HS said that not all such markup is supported by market, so shouldn't be supported backwardsly, right?
16:35:28 <DanC> ACTION HS: propose alternative to 2007Sep/0519 as suggestion to mjs on accessibility/i18n/dev-independence
16:35:39 <DanC> Zakim, next item
16:35:39 <Zakim> agendum 3. "Detailed Spec Reviews, toward 1st public WD of design" taken up [from DanC]
16:36:00 <hsivonen> I said that implementations can't "retain" stuff that isn't already implemented
16:36:11 <oedipus> ok -- was hoping you'd clarify
16:36:31 <oedipus> plus one to survey for public WD of design
16:36:35 <DanC> -> http://www.w3.org/2002/09/wbs/40318/wd7/results Results of Questionnaire What should the HTML WG publish first?
16:36:52 <Julian> +1 as well
16:38:23 <DanC> ACTION DanC: announce re-opened survey on 1st WD priorities, reply to Anne
16:39:07 <DanC> http://esw.w3.org/topic/HTML/SpecReviews
16:39:28 <oedipus> re: HDP, there is an interesting post by Marghanita da Cruz
16:39:34 <oedipus> http://lists.w3.org/Archives/Public/public-html/2007Sep/0542.html
16:40:00 <DanC> DanC: any sections that are thin on review?
16:40:05 <DanC> HS: the new datatemplates section.
16:40:16 <DanC> ack gr
16:40:24 <Zakim> +[Microsoft]
16:41:43 <Chris> Chris has joined #html-wg
16:41:54 <oedipus> zakim, mute Gregory_Rosmaita
16:41:54 <Zakim> Gregory_Rosmaita should now be muted
16:44:19 <oedipus> could resolve to publish at f2f than set window for group not in attendance to yea or nay
16:44:22 <DanC> CW: I'd rather have the ftf meeting before publishing the HTML 5 spec as a W3C WD
16:45:12 <oedipus> either way, it will make progress
16:45:50 <DanC> DanC: I could either put the question before the ftf and announce the results at the ftf, or put the question at the ftf and let everybody take a week after to answer. but can't do both in one day
16:46:24 <DanC> Zakim, next item
16:46:24 <Zakim> agendum 4. "ARIAIntegration" taken up [from DanC]
16:46:49 <DanC> (swapping in http://www.w3.org/html/wg/il16 )
16:46:56 <oedipus> RichS would be best to address -- he is coordinating cross-group conversations
16:48:35 <oedipus> yeah, i met aaronL at a f2f in 2000 or 2001
16:49:50 <oedipus> http://simon.html5.org/specs/aria-proposal
16:49:58 <DanC> (registrants http://www.w3.org/2002/09/wbs/35125/TPAC2007/registrants#html )
16:49:59 <oedipus> latest draft 17 october 2007
16:50:30 <oedipus> neither i nor my screen reader knows for sure
16:50:40 <oedipus> that's why he's called RichS
16:51:25 <oedipus> ChrisW: does the underscore instead of a dash or colon acceptable for ARIA in HTML?
16:51:51 <oedipus> ARIA's basis is an extension of XHTML Role Module
16:52:12 <oedipus> RichS and i are both participants in XHTML2 WG
16:52:19 <hober> I don't see what _ gets us that - doesn't
16:52:47 <oedipus> underscore doesn't break IE's CSS rendering, dash doesn't preclude use of ARIA in SVG
16:53:16 <zcorpan> oedipus, dash doesn't break IE's CSS rendering, either.
16:53:27 <oedipus> no, that's colon
16:53:50 <DanC> (I'm not sure I have energy to scribe this sort of technical detail...)
16:54:06 <DanC> (I think what HS is saying is in public-html email)
16:54:26 <oedipus> colon presents problem for IE support of styling (CSS selectors), dash is problematic for SVG
16:54:50 <DanC> oedipus, could you be a little more explicit about who's saying what?
16:55:25 <DanC> oedipus, if you make a comment in IRC without putting Name: at the start, it gets attributed to you
16:57:10 <oedipus> attempt to find middle ground that is not controversial is point of all the current effort - underscore seems to be the most neutral character
16:57:43 <oedipus> problem is each stakeholder is defending their own turf
16:57:59 <DanC> bummer... time is here.
16:58:02 <DanC> ADJOURN.
16:58:09 <Zakim> -JulianR
16:58:32 <oedipus> underscore an effort to provide solution for HTML as well as XML-based MLs without mucking things up for either
16:58:55 <Zakim> -DanC
16:58:57 <Zakim> -Gregory_Rosmaita
16:59:03 <Zakim> -hsivonen
16:59:08 <Chris> oedipus - underscore, dash, whatever as far as I'm concerned.  I'm not religious.  I just want the solution to be consistent (internally between ARIA properties, and externally in ARIA attributes across vocabularies)
16:59:13 <Zakim> -[Microsoft]
16:59:14 <Zakim> HTML_WG()12:00PM has ended
16:59:15 <Zakim> Attendees were DanC, hsivonen, +49.251.2.aaaa, JulianR, Gregory_Rosmaita, [Microsoft]
16:59:27 <Chris> Zakin, [Microsoft] was me
16:59:33 <DanC> I'll edit minutes and send in the next day or so
16:59:40 <oedipus> chris -- precisely! you've hit the nail on the head -- as long as it works in non-extensible as well as extensible MLs
16:59:52 <hsivonen> oedipus - It seems to me that the underscore is a solution to a problem that doesn't need solving
16:59:53 <Chris> that's it, yes.
17:00:03 <Chris> I think dash works.
17:00:13 <oedipus> hsivonen: could you elaborate?
17:00:18 <Chris> namespaces apparently have some problems in IE, including IE7.
17:00:33 <Chris> We're looking into it; we think it's a bug.
17:00:36 <oedipus> chrisW - yes with regards to application of styling control
17:00:56 <oedipus> chrisW - a bug that dates back to (at least) IE5, i believe
17:01:02 <hsivonen> oedipus: if we want to reserve a prefix, aria- with the hyphen is a non-colliding prefix
17:01:11 <hsivonen> oedipus: Doug wanted to reserve a delimiter
17:01:24 <hsivonen> oedipus: the hyphen is not a non-colliding delimiter
17:01:37 <hsivonen> but I don't think we need to reserve a delimiter
17:01:38 <Chris> oedipus - no, the bug that would need to be fixed is WRT attribute selectors.
17:01:45 <hsivonen> we only need to reserve a prefix
17:01:50 <Chris> (unsupported prior to IE7)
17:02:41 <oedipus> HS - the dlimiter could be parsed as a part of a string as long as that is standardized, just like the colon case
17:02:46 <hsivonen> oedipus: if we want ARIA to look like a consistent part of HTML and SVG, the hyphen is the way to go
17:03:13 <hsivonen> oedipus: but the underscore was specifically for *not* making it look like a normal part of the languages
17:03:21 <oedipus> hmmmm....
17:03:45 <shepazu> if it were just for HTML, that would be fine
17:04:08 <oedipus> underscores aren't that unusual -- think "_DEFANGED.mp3"
17:04:25 <hsivonen> shepazu: well, in SVG stroke properties start with stroke-, so it would be consistent for ARIA properties to start with aria-
17:04:34 <shepazu> but you're asking to impose the lack of proper namespacing on XML in general, not just on HTML
17:04:52 <hsivonen> shepazu: not in general. just for XHTML and SVG
17:04:59 <oedipus> ARIA support shouldn't be based on conventions of known markup languages & dialects today, but provide for future extensibility
17:05:18 <oedipus> for that, it may well need a "special dilimeter"
17:05:35 <shepazu> hsivonen: those are both XML, and we want them to remain XML
17:05:41 <Chris> 1
17:05:45 <hsivonen> ARIA is a way for retrofitting accessibility on legacy languages (HTML and SVG)
17:05:59 <hsivonen> it isn't the preferred solution going forward
17:06:07 <oedipus> it is also a first step -- an intensive triage effort
17:06:27 <shepazu> that's an oversimplification, hsivonen
17:06:33 <hsivonen> shepazu: aria- remains XML as much as stroke- remains XML
17:06:35 <aaronlev> hsivonen: at least not preferred for those things which get their own built-in widget elements
17:07:00 <aaronlev> hsivonen: but it may be the only sensible solution for some thing even going forward
17:07:02 <oedipus> it needs to be available, however, even if not the preferred solution for MLs and widgets that don't have native keyboard  support, for example
17:07:15 <shepazu> hsivonen, why is underscore not acceptable?
17:07:37 <shepazu> give me one technical (not aesthetic) reason it doesn't work?
17:08:17 <hsivonen> shepazu: the reasons are aesthetic, pedagogic and ergonomic
17:08:41 <hsivonen> shepazu: aesthetic, pedagogic and ergonomic reasons are valid reasons
17:09:00 <aaronlev> but not show stoppers
17:09:01 <timbl> timbl has joined #html-wg
17:09:08 <oedipus> hsivonen: what's the ergonomic problem with undercore?
17:09:30 <hsivonen> oedipus: with usual input methods, it is harder to write than the hyphen
17:09:38 <aaronlev> hsivonen: so is < > and :
17:09:56 <shepazu> and you think they outweigh the technical problems that using non-prefixed namespaced attributes cause in XML?
17:10:03 <hsivonen> aaronlev: yes, but that's not a good reason to make things harder
17:10:10 <aaronlev> hsivonen: yes but come on
17:10:10 <Chris> I believe the argument is that underscore looks inconsistent with other vocabularies we already have (e.g. stroke-), and doesn't add any benefit over dash.
17:10:15 <aaronlev> let's fine some common ground and move on
17:10:32 <oedipus> i don't understand why underscore can't serve as common ground?
17:10:35 <Chris> a namespace would be the "right" way to do this - but 1) HTML doesn'there's a namespace issue 
17:10:39 <Chris> erk
17:10:42 <shepazu> Chris: I'd like to use it as another namespacing delimiter
17:10:42 <hsivonen> shepazu: I don't think aria-* prefixed names would cause technical problems in actual Web XML vocabularies
17:10:46 <aaronlev> people have been typing shifted punctuation without complaints since the beginning of html
17:11:01 <oedipus> and CSS thing curly braces
17:11:04 <shepazu> hsivonen: SVG is used on more than just the "Web"
17:11:06 <Chris> but 1) HTML "doesn't have namespaces" (though IE does, in HTML) - and 2) IE has a namespaced attribute updating bug.
17:11:22 <Chris> None of these seem like they should be religious problems.
17:11:36 <hsivonen> Chris: yeah, it is pretty clear that the colon is out
17:11:41 <oedipus> yes, SVG will be used in digital talking books which are evolving into compound document formats
17:11:55 <hsivonen> Chris: it is not just bikeshedding - vs _.
17:12:25 <shepazu> hsivonen: it's pretty clear in your book that the colon is out for HTML, it's not off the table for SVG.. I'm trying to find a compromise solution 
17:13:04 <hsivonen> s/not/now/ in my last line
17:13:17 <Chris> congratulations, you made me look up "bikeshedding"  :)
17:13:36 <oedipus> better the bikeshed than the woodshed...
17:14:18 <shepazu> I think we're getting pushback now because there is a resistance to any kind of namespacing or extensibility among many HTML5 people, and this is a way to do that that they can't argue technically with
17:14:34 <hsivonen> shepazu: I realize that it is a compromise. I'm just saying that it an ugly, inconsistent and less ergonomic compromise. and I don't think there's an actual technical need for it
17:15:31 <shepazu> hsivonen: I'm sorry, I simply don't think that your sense of aesthetics is more important than real technical issues 
17:15:34 <oedipus> ok, so if colon is prettier, why not treat it as simply part of a string for HTML parsing?
17:15:39 <hsivonen> shepazu: fwiw, I've myself suggested the underscore as a way to do extensibility
17:15:46 <shepazu> and you know the technical reasons as well as I
17:15:46 <aaronlev> i think the ergonimc argument is bogus -- it's just as good as most of the punctuation people use for computing and html
17:16:03 <hsivonen> shepazu: I just don't view ARIA as a random extension
17:16:05 <aaronlev> and i wish we would stop talking about how ugly it is, think of the _'s hurt feelings after all
17:16:12 <shepazu> oedipus, colon can't be used properly in IE
17:16:13 <hober> I still don't see the technical argument for _ over -
17:16:15 <aaronlev> i mean, poort underscore
17:16:21 <oedipus> aaronlev: it sure beats whitespace delimiters...
17:16:23 <hsivonen> hober: there is none
17:16:24 <aaronlev> i think it's cute
17:16:34 <aaronlev> it's humble
17:16:44 <shepazu> self-effacing
17:16:51 <oedipus> it will work, which is the only thing we are ALL after
17:17:30 <shepazu> hsivonen: please stop spinning the truth... you may not agree with the technical goal, but there is one
17:17:32 <aaronlev> taoism says that true power is being the lowest, not the highest- and the underscore realizes that, it's a deeper understanding of power to be humble
17:17:49 <aaronlev> dear, humble, powerful underscore
17:18:07 <hober> What's the technical argument for aria_?
17:18:18 <hsivonen> hober: compared to what?
17:18:25 <oedipus> aaronlev: "A man of the highest benevolence acts, but from no ulterior motive. A man of the highest rectitude acts, but from ulterior motive.  A man most conversant in the rites acts, but when no one responds rolls up his sleeves and resorts to persuasion by force." -- Lao Tsu, Tao Te Ching
17:19:20 <shepazu> hober: in HTML, it can serve as just another string, in XML, it could serve as a namespace delimiter so that SVG and XHTML could use proper namespacing
17:19:44 <oedipus> shepazu: right
17:19:46 <hsivonen> shepazu: it is just a string in XML, too
17:19:49 <aaronlev> seriously the aestethic argument and the ergonomic argument are really lifeless
17:19:50 <hober> XML already has a namespace delimiter.
17:20:17 <oedipus> hober: yes, but there is a struggle over what namespace
17:20:22 <shepazu> hober: but the colon, the current NS delimiter, does work in IE and CSS properly
17:20:25 <hsivonen> hober: yes, but this way the all the trouble that Namespaces in XML cause are sidestepped
17:20:37 <hsivonen> hober: no namespace resolution happens technically
17:20:50 <hsivonen> hober: only in terms of spec organization
17:21:27 <shepazu> hober, please read http://www.schepers.cc/?p=46 act III scene III (the bottom)
17:22:44 <hsivonen> shepazu: fwiw, I think you kill any benefit of the _ delimiter if you try to make the XML layer aware of it
17:23:00 <oedipus> hsivonen: how so?
17:23:00 <hsivonen> shepazu: the whole trick is that the XML layer doesn't tamper with it
17:23:20 <shepazu> no, the whole trick is that IE and CSS work with it
17:23:58 <hsivonen> oedipus: now it is a simple string as far as APIs and parsing all treat it the same way and don't try to do any further processing
17:24:00 <shepazu> it won't harm existing, unaware XML processors, and can be used in supporting XML processors
17:24:52 <hsivonen> shepazu: if a new underscore-aware DOM API was released, we'd be back to the point of having an API difference with pre-existing browsers
17:25:03 <oedipus> ARIA is being held hostage to others' religio/philosophic/implementation-decisions -- it should be absolutely neutral so it can be ubiquitously applied
17:25:56 <hsivonen> oedipus: yes
17:25:59 <aaronlev> oedipus: i think it will be resolved
17:26:09 <aaronlev> it's absurd for it to not be
17:26:40 <oedipus> ARIA politeness levels model will ALWAYS be necessary, and the point is to enable a user to have a uniform method of setting them client side, so that they are not only widely implemented, but widely used
17:26:50 <shepazu> actually, it's not necessary to treat an underscore itself as special... it would be the registered "nsname + _"
17:27:21 <oedipus> hsivonen and aaronlev: at least we've got a toe on some common ground!
17:27:33 <shepazu> that would be the minimal token of meaning, not the underscore
17:27:34 <aaronlev> we're just half a character apart
17:27:55 <zcorpan> shepazu: could you please outline exactly (e.g. write a draft spec) how you think this underscore namespacing idea should work?
17:28:10 <zcorpan> shepazu: because i'm completely lost there
17:28:31 <shepazu> zcorpan: it doesn't apply to HTML, which isn't NS aware
17:28:47 <shepazu> aria_* would just be treated as a string in HTML
17:29:09 <hober> Why does the solution to the "using ARIA in HTML, XHTML2, and SVG" problem need to be a generalized namespacing thing?
17:29:16 <shepazu> and I don't think this should be gated on my having the time to create a proposal beyond what I've already written
17:29:20 <zcorpan> shepazu: the DOM is namespace aware. do you suggest that aria_ would have different processing on the DOM if it came from parsing HTML or parsing XML?
17:29:49 <hsivonen> hober: it doesn't need to be a generalized thing, IMO
17:29:55 <zcorpan> shepazu: if so, i would object, because the whole point of aria- was to have the *same* processing in both cases
17:30:11 <hsivonen> zcorpan: exactly
17:30:14 <shepazu> zcorpan: that's not what I said
17:30:24 <zcorpan> shepazu: please clarify, then
17:30:43 <shepazu> it would have the same processing, just not the same parsing
17:30:56 <hsivonen> shepazu: I don't follow
17:31:21 <shepazu> in HTML5, the string "aria_*" would be enough (presumably) to put it into the aria ns
17:31:23 <hsivonen> shepazu: the key feature of it is that the parser and the DOM don't try to process the prefix in any special way
17:31:45 <hsivonen> shepazu: that it is just a naming convention the parser and the DOM know *nothing* about
17:32:06 <shepazu> hsivonen: are you saying that you won't treat aria properties as being in the aria NS?
17:32:16 <zcorpan> right
17:32:21 <hsivonen> shepazu: yes. that's the whole point
17:32:24 <zcorpan> the attributes are in no namespace
17:32:39 <zcorpan> if we want to have different parsing in html and in xml, then we can use the colon.
17:33:06 <shepazu> colon doesn't work in IE and CSS
17:33:30 <hsivonen> shepazu: doing special processing with the underscore doesn't either
17:34:38 <shepazu> hsivonen: the syntax and functionality would be the same in XHTML, SVG, and HTML, even if the DOM tree isn't 
17:34:48 <shepazu> and that's what matters to authors
17:34:54 <hober> not to script authors
17:35:09 <shepazu> rather, to authors that don't understand about namespaces
17:35:15 <hsivonen> shepazu: but we want the DOM tree to work the same for script authors in HTML and in XHTML in shipped browsers and in future browsers
17:35:23 <hober> hsivonen: exactly
17:36:03 <aaronlev> yeah i'd like them to be in no namespace as well
17:36:15 <aaronlev> and have it work the same in the dom no matter what
17:36:17 <shepazu> then I'll have to think about it... it seems that you keep adding more constraints on this to make it more difficult to do
17:36:35 <hsivonen> shepazu: it isn't difficult to do at all
17:36:35 <aaronlev> it makes it simpler to implement that way, for the browser and author
17:36:47 <hsivonen> shepazu: you make it harder by inventing additional processing
17:36:57 <hsivonen> shepazu: the whole point is not to have additional processing
17:37:00 <zcorpan> shepazu: we've had the same constraints all along
17:37:50 <shepazu> in HTML, yes, but now you're adding constriants to XML languages like XHTML and SVG as well
17:37:53 <zcorpan> "The processing should be the same for both HTML and XHTML." -- http://lists.w3.org/Archives/Public/public-html/2007Sep/0516.html
17:38:00 <shepazu> which doesn't sit well with me
17:39:09 <hober> Hmm. In two of those three cases (HTML5 and XHTML5), we clearly want the DOM to be the same, right? How are we additionally burdening XHTML5?
17:39:09 <shepazu> aaronlev: why do you want them to be in the null NS?
17:39:27 <aaronlev> to avoid extra processing
17:39:37 <aaronlev> and differences between how we handle it in text/html vs. all else
17:39:56 <aaronlev> actually separating the attributes into 2 components just confuses things
17:40:01 <aaronlev> don't see what it adds
17:40:15 <hsivonen> shepazu: the thing is that the text/html legacy affects to DOM and XHTML and SVG inherit the DOM
17:40:22 <hsivonen> shepazu: the power of legacy is huge
17:40:29 <hsivonen> shepazu: but that's how it is
17:41:06 <aaronlev> i agree with that too
17:41:08 <shepazu> well, maybe we don't have a way forward after all, unless someone can propose something else
17:41:31 <oedipus> hsivonen: yes, but the gaps in support for legacy is even "huger"
17:41:48 <aaronlev> shepazu: what's the barrier with allowing aria attributes in no namespace within SVG? is it philosophical or practical
17:41:51 <hsivonen> oedipus: I don't understand your point
17:42:41 <oedipus> if we are bound by legacy implementations, and throw away anything that isn't 100 per cent supported, then there is no alternative but ARIA to provided the needed semantics and bindings
17:43:01 <shepazu> aaronlev, it won't validate (which is a bellweather for proper processing in XML-aware applications besides browsers)
17:43:51 <shepazu> oops, bellwether
17:44:00 <hsivonen> shepazu: it will validate if you use a suitable schema
17:44:30 <mjs> mjs has joined #html-wg
17:45:17 <kingryan> kingryan has joined #html-wg
17:45:21 <hsivonen> shepazu: if you want to validate against a fixed pre-existing schema, you can't add any syntax features (except ones that subvert the expressive power of the schema)
17:46:21 <shepazu> you can with NVDL
17:46:52 <hsivonen> shepazu: if you have a namespace wildcard, you are effectively just punching "don't care" holes in your schema
17:47:05 <hsivonen> shepazu: that is, choosing not to validate parts
17:47:19 <shepazu> that's not what I said
17:47:25 <hsivonen> shepazu: I don't see how choosing not to validate parts makes sense with the validation argument
17:47:46 <shepazu> you split those sections off to validate against their own schema, not the SVG schema
17:48:07 <gavin_> gavin_ has joined #html-wg
17:48:08 <hsivonen> shepazu: you are letting validation to wag the spec and then implementation
17:48:16 <hsivonen> that's totally backwards
17:48:22 <hsivonen> implementations should wag the spec
17:48:33 <shepazu> and even if that weren't the case, there is still value in validating just the SVG parts
17:48:33 <hsivonen> and validation is the tip of the tail that the spec wags
17:48:51 <shepazu> hsivonen: no, that's not what I'm doing, as I explained yesterday
17:49:14 <shepazu> I agree (as I agreed yesterday) that validation is the end tool
17:49:18 <shepazu> not the driver
17:49:33 <oedipus> hsivonen: shepazu's validate against own schemas makes sense in CDF terms
17:50:19 <shepazu> but as I said a few lines early, validation is not for validation's sake, it's to indicate if the document can work properly in XML processing tools
17:50:27 <hsivonen> shepazu: you are basically saying that you choose not to copy and paste aria attributes into your schema and in addition choosing to be limited to the ways of filtering the infoset that NVDL provides
17:52:29 <shepazu> hsivonen: ARIA is a new technology, and despite what you claim they *should* do, they very well may have differences between v1 and v2, and we don't want to lock down the functionality in SVG when there is a perfectly good existing extensibility mechanism (that you just don't happen to like)
17:52:50 <shepazu> I'm really tired of this anti-ns religion
17:52:58 <hsivonen> shepazu: are we now moving along from validation?
17:53:20 <shepazu> what?
17:53:34 <hsivonen> shepazu: I saw a change of topic
17:53:46 <shepazu> I don't see where
17:54:14 <hsivonen> shepazu: you didn't comment on the contraints on schemas and validation technology you chose
17:54:29 <hsivonen> shepazu: anyway, legacy HTML doesn't have namespaces in the DOM
17:54:45 <hsivonen> shepazu: ergo, introducing namespaces causes scripting differences
17:55:04 <shepazu> hsivonen: I did comment on it... the very next line...
17:55:36 <hsivonen> shepazu: I saw that as discussing versioning and incompatible changes
17:55:42 <shepazu> yes...
17:56:19 <shepazu> you want us to put ARIA v1 in our schema... and if we did that, we'd be locked down to that version
17:56:33 <shepazu> I guess we could make multiple schemae
17:56:52 <hsivonen> shepazu: as for how easy namespaces are for authors, I think the fact that we have spent so much time clearing confusion about what people mean in what case
17:56:57 <hsivonen> and how namespaces work
17:56:57 <shepazu> but that's a slippery slope
17:57:02 <hsivonen> is proof that they are too hard
17:57:42 <aaronlev> this discussion is really a major root of the problem
17:57:49 <shepazu> hsivonen: an author doesn't need to understand all the intricacies of schema validation and such to *use* namespaces 
17:57:55 <aaronlev> many people in w3c have vastly different opinions on namespaces
17:57:55 <hsivonen> shepazu: you'd only be locked if you placed constraints on yourself saying that you cannot publish updated schemas
17:58:25 <hsivonen> shepazu: HTML5 deals with this by decoupling the schemas from the spec
17:58:41 <zcorpan> as far as i'm concerned, it doesn't matter whether the svg or html specs even mention ARIA, or what any schemas contain. i care about the DOM being the same, the syntax being the same in different serializations, and having it implemented interoperably.
17:58:46 <hsivonen> shepazu: the schemas fantasai and I have written can be fixed independently of spec
17:59:21 <shepazu> hsivonen: and that works for HTML, where you have already said there isn't any goal of making it blend well with other languages
17:59:46 <hsivonen> shepazu: the being locked reason is not a technical reason. it is just that a WG decides that they have to publish a frozen schema 
17:59:55 <shepazu> we're having to claw and scrabble and dig for ways to make SVG work with your parser, while with XHTML, it just works
18:00:04 <shepazu> no, it's not, hsivonen
18:00:21 <oedipus> zcorpan: i strongly support your statement about the importance of the DOM being the same, the syntax the same, and the implementation interoperable
18:00:40 <zcorpan> oedipus: ok :)
18:00:57 <shepazu> do I also then have to publish a schema for how SVG works with XHTML, XForms, MathML, CellML, MusicML, etc, and any combination of those?
18:01:18 <hober> shepazu: I don't think you have to publish any schemas.
18:01:24 <shepazu> how many schemae do we have to write?
18:01:32 <zcorpan> shepazu: 0.
18:01:39 <hsivonen> shepazu: you don't need to write any. you can leave it to others
18:01:51 <hsivonen> shepazu: just like the WG doesn't ship a browser
18:02:21 <shepazu> so, anytime an author wants to mix namespaces, they have to first learn how to write schemae? *that* seems like an undo burden on authors
18:02:39 <hober> Why do you need schemas to mix namespaces?
18:02:49 <hsivonen> shepazu: no, they go and download an Open Source schema implementation
18:02:57 <hsivonen> hober: you don't
18:03:13 <zcorpan> or they don't care about schemas
18:03:27 <shepazu> hsivonen: oh, does Open Source" have a magical schema-writing elf?
18:03:45 <hsivonen> shepazu: for HTML5, that's me
18:03:55 <briansuda> briansuda has joined #html-wg
18:03:57 <shepazu> hsivonen: you are a smart guy
18:04:10 <shepazu> and you know a lot about this domain
18:04:49 <hober> I see two advantages of leaving a schema out of a spec - 1. you don't have conflicts between normative text and normative schema, and 2. you shift the implementation burden to the people who think they actually need a schema.
18:05:03 <shepazu> but does every combination of XML dialects (or any language) need to have a smart, knowledgeable, dedicated guy like you to do this?
18:05:24 <briansuda> briansuda has joined #html-wg
18:05:56 <hober> Where does this need come from?
18:05:58 <hober> I don't get it.
18:06:04 <hsivonen> shepazu: well, *someone* has to write a schema if a schema is to be written. so yeah, you need someone to do it
18:06:05 <zcorpan> shepazu: if people need schemas, schmeas will be written
18:06:06 <shepazu> hsivonen: your "write a new schema" answer is not extensible, and you know it
18:06:08 <hsivonen> in or out of WG
18:06:31 <hsivonen> shepazu: my copy a schema and edit it is extensible
18:06:43 <shepazu> with namespaces, you don't need these extra schemae
18:07:01 <hober> with or without namespaces, you don't need schemas
18:07:08 <hsivonen> shepazu: yes, you do. or you leave "don't care" unvalidated holes
18:07:11 <briansuda> briansuda has joined #html-wg
18:07:21 <shepazu> you just use NVDL and process each fragment according to its own schema
18:07:36 <hsivonen> shepazu: then you are contrained by what NVDL lets you do
18:07:45 <hsivonen> shepazu: and the tip of the tail is wagging the dog
18:07:52 <hsivonen> constrained even
18:08:33 <shepazu> there are always constraints in any formal grammar.... HTML5 has tons of constraints, don't use that BS argument to make it look like I'm "constraining" anything unduly
18:08:46 <hsivonen> fwiw, existing schema technology is woefully inadequate for capturing the conformance criteria for HTML5
18:09:16 <hsivonen> I have a lot of hand-rolled Java code in there to fill the gaps
18:09:28 <shepazu> that's HTML5, that's not XML's problem
18:09:50 <gavin> gavin has joined #html-wg
18:10:06 <hsivonen> shepazu: thinking XML languages don't have dark areas that schemas don't cover isn't realistic
18:10:11 <shepazu> because XML has been strict from the first (except XHTML), there is very little invalid, ill-formed XML out there
18:10:32 <hsivonen> shepazu: with HTML5, the schema layer operates on a strict tree
18:10:34 <shepazu> hsivonen: sur, but not huge gaping holes right in the middle
18:10:37 <hober> tell that to the feedparser
18:10:44 <hsivonen> shepazu: when I said Java, I didn't mean the parser
18:10:54 <hsivonen> shepazu: I meant code on a higher layer
18:11:07 <zcorpan> ...that also applies to XHTML5
18:11:22 <zcorpan> e.g. overlapping cells are non-conforming
18:11:30 <shepazu> well, I have work to do, and we're not getting anywhere here
18:11:40 <hsivonen> zcorpan: that's a great example
18:12:07 <hsivonen> fwiw, the official Atom RELAX NG schema totally sucks compared to the Python Feed Validator
18:12:11 <shepazu> that's a great example... of something that doesn't happen in validated XML
18:12:28 <hober> also, note that Atom's schema is informative, not normative.
18:12:30 <zcorpan> shepazu: you can have overlapping cells in XHTML5
18:12:42 <zcorpan> shepazu: and XHTML 1.0 for that matter
18:13:05 <hsivonen> shepazu: I'd love to see a schema that enforces table integrity
18:13:30 <hsivonen> shepazu: with colspans and rowspans
18:13:42 <shepazu> how can you have overlapping cells in XHTML1?
18:14:07 <zcorpan> you have a table with two rows and two columns
18:14:12 <shepazu> you mean overlapping elements, or just table cells?
18:14:19 <zcorpan> one cell spans the row and another spans the column
18:14:27 <zcorpan> with rowspan="2" and colspan="2"
18:14:33 <zcorpan> table cells
18:14:35 <dbaron> dbaron has joined #html-wg
18:14:38 <zcorpan> not misnested tags
18:14:43 <shepazu> oh
18:14:50 <shepazu> that's not what I was talking about
18:15:03 <shepazu> that's just referencing
18:15:11 <hsivonen> <table><tr><td/><td rowspan='2'/></tr><tr><td rowspan='2'/></tr></table>
18:15:19 <hsivonen> doh
18:15:25 <hsivonen> <table><tr><td/><td rowspan='2'/></tr><tr><td colspan='2'/></tr></table>
18:15:48 <shepazu> that looks well-formed to me
18:15:53 <zcorpan> yes
18:15:55 <hsivonen> shepazu: it isn't conforming
18:16:10 <zcorpan> shepazu: the cells overlap, and overlapping cells are non-conforming
18:16:11 <shepazu> I didn't say anything about that
18:16:27 <hsivonen> shepazu: writing a validator that only checks for well-formedness is putting the bar really low :-)
18:17:00 <shepazu> like I said, it's just a first step toward real usability... that doesn't invalidate anything I've said
18:17:07 <shepazu> I have to go
18:17:13 <shepazu> ttyl
18:17:15 <hsivonen> see you
18:18:57 <zcorpan> since the underscore namespace idea seems to be incompatible with the goals of ARIA (namely that the DOM would be different), it seems unwise to use underscore for ARIA since that would in turn block the underscore for the namespace idea
18:19:23 <zcorpan> i don't object to the namespace idea in general
18:20:08 <zcorpan> (even though i don't understand how it would work yet)
18:20:09 <aaronlev> aaronlev has joined #html-wg
18:20:39 <zcorpan> (or perhaps *because* i don't understand how it would work yet)
18:20:47 <shepazu> no, the whole point of doing underscore for namespacing was a way to work aria into both HTMl and SVG with compatible syntax
18:21:07 <shepazu> without that, underscore means nothing
18:21:23 <shepazu> so I'd argue we should still use it
18:21:49 <zcorpan> in the current spec, it means nothing
18:21:50 <shepazu> because it makes aria attributes more distinctive
18:21:58 <hober> why can't we use aria- in both HTML and SVG?
18:22:30 <shepazu> ok, I'm out of here.... this is where I came in
18:22:43 <krijnh> krijnh has joined #html-wg
18:36:09 <Dashiva> Considering the recent aria discussion, I need to remove dash from my highlights
18:37:22 <zcorpan> dash dash dash dash dash dash ;)
18:37:32 <Dashiva> Too late, already disabled it :P
18:37:39 <zcorpan> :(
18:40:30 <timbl> timbl has joined #html-wg
18:40:47 <aaronlev> aaronlev has joined #html-wg
18:46:15 <shepazu> zcorpan, I thought about what you said about the DOM... I have a proposal
18:46:27 <shepazu> get/setAttribute would still work with my scheme, but get/setAttributeNS would fail if used differently in HTML vs. SVG, because in SVG, the attributes would be in the ARIA namespace while in HTML they would be in the 'null' namespace.  Also, the processing model would yield slightly different trees (not the shape of the tree, but only the namespace property for the ARIA attributes).  Do you really see that as a blocker?  It's not that much extra processing
18:47:07 <hasather> hasather has joined #html-wg
18:47:54 <hsivonen> shepazu: redefining how XML to DOM mapping works is a pretty big deal, so yeah, I'd consider it a blocker
18:48:14 <hsivonen> shepazu: also, we want scripting to work the same way with HTML5 and XHTML5
18:48:54 <shepazu> hsivonen: it would, if you used get/setAttribute... they would act as if the element were in the null NS
18:49:48 <hsivonen> you'd still be redefining how DOM Core works
18:49:57 <shepazu> in what way?
18:50:15 <hsivonen> by putting non-colon attributes in a namespace
18:50:50 <shepazu> no, that's the symptom... where does it say in DOM Core that you can't do that?
18:51:13 <hsivonen> shepazu: shipped implmentations don't do it
18:51:13 <shepazu> (I'm not saying it doesn't, I'm just asking for proof)
18:51:31 <shepazu> hsivonen: shipped implementations don't do ARIA, either
18:51:40 <hsivonen> that's different
18:51:45 <shepazu> I don't see how
18:51:47 <hsivonen> different layers
18:51:49 <shepazu> it's adding a feature
18:52:02 <hsivonen> changing the DOM shakes the foundation
18:52:10 <shepazu> that's hyperbole
18:52:46 <shepazu> and metaphor... not real technical evidence
18:53:04 <zcorpan> shepazu: changing how the DOM Core methods work is way out of scope
18:53:20 <zcorpan> and i don't see the benefit of doing so
18:53:28 <shepazu> the scope of this goes beyond ARIA
18:53:43 <zcorpan> and the HTML WG and the SVG WG
18:53:52 <shepazu> yes, of course
18:53:54 <shepazu> so?
18:54:07 <shepazu> you're asking for a major change to how XML processing is handled, anyway
18:54:15 <zcorpan> no, i'm not
18:54:22 <shepazu> this is just an alternate change
18:54:26 <zcorpan> the xml processor would not be changed
18:54:36 <zcorpan> the dom core methods would not be changed
18:54:38 <shepazu> not in browsers, but in other UAs
18:54:38 <zcorpan> under my proposal
18:54:39 <hsivonen> shepazu: no, the whole point is *not* asking for any change to XML or DOM Core
18:54:59 <zcorpan> exactly
18:55:01 <shepazu> what's wrong with asking for an extensible addition to XML or DOM Core?
18:55:23 <zcorpan> it breaks compat with existing implementations
18:55:30 <shepazu> no, it wouldn't
18:56:07 <shepazu> get/setAttribute would still work the same, as would get/setAttributeNS in non-supporting browsers
18:56:44 <zcorpan> the NS methods would do different things in legacy implementations and new implementations
18:56:46 <shepazu> and authors would be encouraged not to use the NS-aware methods (which they wouldn't be doing anyway, in your scheme)
18:56:46 <hsivonen> shepazu: working differently in supporting and non-supporting browsers would be the problem
18:57:00 <hsivonen> shepazu: just like with the colon, IE does different things now
18:57:25 <oedipus> hsivonen: that's IE's problem not an inherent defect
18:57:59 <hsivonen> oedipus: shipped IE out there is a constrain on what we can and cannot do
18:58:13 <hsivonen> oedipus: inherentness does not matter
18:58:20 <zcorpan> oedipus: it's a compat problem between implementations
18:58:20 <hsivonen> oedipus: nor whose fault it is
18:58:22 <hober> if it were, we could just use the colon
18:58:26 <hober> *were not
18:58:29 <hsivonen> oedipus: legacy just is
18:59:03 <oedipus> hsivonen: i know legacy just is -- that's why ARIA is so important
18:59:59 <oedipus> for backwards and forwards compatibility; i don't want to sacrifice future uses of ARIA or ARIA-like models on the altar of legacy -- 
19:00:15 <jgraham> DanC: I entirely forgot about the telecon, otherwise I would have been :)
19:01:11 <hsivonen> oedipus: the best way not to sacrifice ARIA is to use aria-* (the second best is aria_*) and not changing anything about how parsing and the DOM work
19:01:41 <shepazu> that's the best way for HTML, not for other languages
19:02:00 <hsivonen> shepazu: in browsers, the other languages live in the same DOM
19:02:17 <hober> right, that's why DOM-equivalence is so key
19:02:22 <shepazu> but the other languages are used outside the browser!
19:02:40 <hsivonen> shepazu: but also in the browser
19:02:49 <hsivonen> shepazu: that's why the legacy applies
19:02:59 <hober> if the other languages are used to create a DOM in a non-browser context, that DOM should be as similar as possible to a browser DOM, it seems to me
19:03:00 <DanC> hi jgraham ; are you interested to help maintain an HTML WG issues list? (have you read the telcon notes?)
19:03:19 <hsivonen> the WHATWG was formed because people thought outside the browser
19:03:47 <shepazu> yes, but my solution at least approaches some bridge between the two worlds, and yours doesn't
19:03:48 <hsivonen> the DOM sucks so badly that if you aren't in a browser, you should probably use something else
19:03:51 <hsivonen> like ElementTree
19:04:10 <hober> html5lib is my bridge between the two worlds :)
19:04:11 <oedipus> hsivonen: really?  it strikes me that it was formed because people were thinking intensely about their own browsers and implementations
19:05:05 <hober> I want to write non-browser code that operates on a mix of languages at the DOM level. I don't want that DOM code to differ from in-browser DOM code I might write.
19:05:16 <hsivonen> oedipus: yes, the very real needs of browsers were overlooked
19:05:40 <shepazu> hsivonen: so now it's the browser's turn to ignore everyone else?
19:05:50 <shepazu> we aren't 6-year-olds, hsivonen
19:05:55 <hsivonen> when I write non-browser code, I want the infoset to look the same regardless of serialization
19:06:41 <hsivonen> shepazu: no, it's not about ignoring everyone else. it is about taking the contraints browsers face as constraints.
19:06:52 <oedipus> hober: your point is quite well taken
19:07:26 <oedipus> hsivonen: browsers face or their implementors face?
19:07:36 <shepazu> hsivonen: we are trying to take *all* constraints, browser and non, into account... you were speaking as if the browser was the only set of constraints
19:08:14 <hsivonen> shepazu: browser constraints are *very* important, because they are what people use to interact with the Web
19:08:25 <shepazu> hsivonen: I agree completely
19:08:44 <shepazu> do you also agree that the other constraints are important?
19:08:55 <hober> what are the other constraints?
19:09:02 <hober> it's hard to be abstract about them
19:09:08 <hsivonen> shepazu: I think Web specs should be for the Web foremost
19:09:27 <shepazu> hsivonen: that doesn't really answer the question
19:09:29 <hsivonen> shepazu: if other constraints and Web contraints are opposed to each other, the non-Web contstraints should yield
19:09:53 <shepazu> but we don't need to set up artificial oppositions
19:09:59 <hsivonen> oedipus: browser implementor face with the reality of the market
19:10:01 <oedipus> hsivonen: tell that to the DAISY consortium, whose goal is to provide digital talking books that can be processed/parsed on the web, on dedicated devices, and generic-non-web devices
19:10:29 <oedipus> including delivery to mobile devices
19:10:50 <shepazu> we need to find ways that address the various needs of browsers and non, not just say it can't be done
19:11:03 <hsivonen> oedipus: the kinds of ebooks I care about are the ones I can read in my Real Browser on a mobile device
19:11:32 <hsivonen> oedipus: that is, HTML ebooks
19:11:33 <oedipus> hsivonen: yes, but when the market is so closed and constrainted; and as for ebooks, you and i should be able to read the same release at the same time no matter the modality
19:12:15 <zcorpan> shepazu: could you please list exactly what the non-browser constraints are, and for whom those are constraints? and why? i'm not sure i understand that still
19:12:22 <hsivonen> oedipus: the HTML ebooks I've read on a mobile device weren't created for mobile devices. I just put them on one
19:14:46 <zcorpan> btw, i need to leave now, i'll check the log tomorrow
19:15:05 <DanC> have a good one
19:16:21 <timbl> timbl has joined #html-wg
19:30:31 <jgraham> DanC: Sure I guess I still have some free time :) (it's taken me a while to read the backlog, hence the slow response)
19:33:41 <DanC> speaking of backlog and slow response, I'm now in a phone meeting. glad to hear you're interested. I'll be in touch!
19:33:53 <mjs> mjs has joined #html-wg
19:55:45 <gavin_> gavin_ has joined #html-wg
20:22:48 <krijnh> krijnh has joined #html-wg
20:46:33 <mjs> mjs has joined #html-wg
22:03:32 <gavin_> gavin_ has joined #html-wg
22:06:47 <beowulf> beowulf has joined #html-wg
22:16:24 <mjs> mjs has joined #html-wg
22:19:41 <anne> anything new?
22:21:59 <kingryan>  yeah, anne, we decided to ditch html5 and work on xhtml2
22:23:22 <anne> sounds sensible
22:27:32 <kingryan> and we're gonna write xhtml2 in rdf
22:27:50 <hsivonen> anne: do you see the scrollback after the telecon?
22:28:04 <hsivonen> anne: changes to DOM Core were suggested
22:28:34 <jgraham> <-- this needed a </satire>
22:29:05 <jgraham> At the start of what hsivonen said
22:29:14 <Hixie> have we considered no delimiter at all?
22:29:16 <Hixie> ariadisabled?
22:29:18 <Hixie> ariachecked?
22:29:24 <Hixie> that would actually fit into HTML5 even better
22:29:38 <jgraham> yuck
22:29:54 <Hixie> it's what most html attributes are like
22:30:47 <jgraham> most html attributes don't have an acronym as their first part and aren't being logically grouped by their first part
22:37:30 <anne> hsivonen, is that the thingie with the underscore?
22:37:43 <anne> hsivonen, I was hoping I could ignore that
22:38:33 <hsivonen> anne: what's the thingie with underscore?
22:39:39 <anne> the changes to DOM Core
22:39:46 <hsivonen> anne: yes
22:40:10 <hsivonen> which, of course, is totally missing the point of not using the colon
22:41:23 <anne> yeah, dunno
22:41:40 <anne> seems like it's not really worth discussing this anymore as no technical arguments are put forward
22:41:51 <Hixie> can we use the hyphen then?
22:41:57 <anne> i'd say yes
22:42:15 <Hixie> just "disabled"?
22:42:16 <anne> well, with aria as prefix instead of aria-
22:42:19 <Hixie> ah yes
22:42:22 <Hixie> i'm starting to like that too
22:44:14 <jgraham> I don't have a strong opinion on - v _ except that the _ solution seems to be tied to also solving an even harder problem, but I really don't like not having a separator purely on aesthetic grounds
22:52:54 <anne> whoa, lots of comments on SVG in text/html
22:53:14 <anne> that's probably a (recent) record for comments on my blog
22:53:36 <anne> that all those people are willing to write markup
23:00:46 <anne> ah I see, other people linked
23:01:48 <Hixie> i love "Since most SVG is tool-generated, there's no compelling reason to "simplify" the syntax"
23:01:59 <Hixie> I would have said "Since most SVG is tool-generated, there's a compelling reason to "simplify" the syntax"
23:03:12 <Hixie> i don't really understand why svg wants to be in text/html though... i mean, isn't it just a supercharged font tag?
23:05:49 <anne> does it make it any better when it's in a data: URL?
23:07:45 <anne> I don't really want to become an advocate of presentational markup, but sometimes little shorthands are convenient and not really harmful
23:08:44 <anne> The argument that things are not black / white applies to "semantic markup" as well, I think
23:09:53 <polin8> polin8 has joined #html-wg
23:15:38 <jgraham> Indeed, I view semantic markup as a means to an end
23:17:37 <sbuluf> sbuluf has joined #html-wg
23:19:49 <kingryan> jgraham: semantics have to be functional to be meaningful
23:24:44 <jgraham> kingryan: if I understand you correctly, that may depend on the definition of functional and meaningful you choose. However I'm going to sleep now rather than thinking about the semantics of semantics :)
23:25:19 <Thezilch> Thezilch has joined #html-wg
23:25:31 <jgraham> you may want to check if html5lib/ruby passes the tests I just checked in - for some reason my ruby isn't set up right
23:25:50 <timbl> timbl has joined #html-wg
23:26:03 <kingryan> jgraham: good point and I'll check it out
23:34:25 <Hixie> anne: well, consider it from the point of view of an aural browser or lynx or something like that
23:49:36 <olivier> olivier has joined #html-wg