/irc-logs / w3c / #html-wg / 2007-05-04 / end

Options:

# Session Start: Fri May 04 00:00:00 2007
# Session Ident: #html-wg
# [00:01] <hyatt> what long email
# [00:32] <h3h> long emails don't seem to have much effect
# [00:32] <h3h> I think huge diagrams might be more effective
# [00:32] <h3h> only half-joking.
# [00:32] <Dashiva> Cliff notes?
# [00:33] <Philip`> I have some ineffective huge diagrams, which are arguably less useful but much easier to produce
# [00:33] <jgraham> h3h: SVG email?
# [00:34] <h3h> :)
# [00:37] <Dashiva> powerpoint email, next step up from html email
# [00:37] <mjs> use Keynote instead, it's well-formed XML
# [00:46] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
# [00:58] * Quits: tH (r@87.102.32.222) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [01:00] * Joins: EricPuidokas (eric@65.34.6.69)
# [01:02] <EricPuidokas> Has there been any discussion of a better implementation for "Skip to navigation" accessibility links?
# [01:02] * Joins: myakura (myakura@125.194.247.196)
# [01:11] <zcorpan_> EricPuidokas: i think the <article> and <nav> elements are intended to replace the need for skip links
# [01:12] <EricPuidokas> ahh okay
# [01:12] <EricPuidokas> where are the docs on the new elements?
# [01:13] <hasather> EricPuidokas: http://www.whatwg.org/specs/web-apps/current-work/
# [01:13] <hasather> EricPuidokas: this might help too: http://simon.html5.org/html5-elements
# [01:17] <EricPuidokas> is there any type of article container to associate multiple articles together?
# [01:18] <zcorpan_> <section>
# [01:18] <zcorpan_> (or just <body>)
# [01:19] <zcorpan_> (if all you have is a bunch of <article>s)
# [01:22] <Zeros> zcorpan_, how do they replace the need for skip links?
# [01:23] <EricPuidokas> well that would replace the "skip to nav" one
# [01:23] * Quits: billmason (billmason@69.30.57.156) (Quit: .)
# [01:23] <Zeros> Only in screen readers that knew what it was
# [01:24] <hasather> Zeros: a UA could let the user go directly to the nav elements
# [01:24] <Zeros> ah. I suppose. You'll still need to provide skip to nav and such links to be accessible for a long while though
# [01:25] <EricPuidokas> I don't know if the <article> element solves the "skip to content" part tho
# [01:26] <EricPuidokas> There are types of content that shouldnt go in the article tag, right?
# [01:26] * DanC is away: family time
# [01:26] * Parts: DanC (connolly@128.30.52.30) (Client exiting)
# [01:27] <hasather> EricPuidokas: yea, nav for example, or headers and footers
# [01:27] <hasather> + others
# [01:31] <EricPuidokas> if i have a list of links to articles, like on a news site, would each link go inside its own article element?
# [01:33] * Quits: schepers_ (schepers@69.134.24.226) (Quit: Free at last!)
# [01:34] <hasather> EricPuidokas: I'd say no
# [01:36] <Zeros> EricPuidokas, <aside> would probably work if you wanted a list like "Recent Entries"
# [01:38] <EricPuidokas> so a page like nytimes.com would be full of tons of <aside> elements?
# [01:39] <EricPuidokas> (tons= ~20)
# [01:41] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Ping timeout)
# [01:44] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [01:46] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Connection reset by peer)
# [01:48] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [01:48] * hyatt is massively confused by wf2's repetition model
# [01:49] <hyatt> Hixie: yt?
# [01:51] <Philip`> I hadn't really looked at WF2 before, but it seems quite neat how it already addresses at least three of the repetition concerns John Boyer listed
# [01:51] * Philip` reads it more to see if he can work out another of the concerns
# [01:52] <zcorpan_> hyatt: what are you confused about?
# [01:53] <Philip`> Oh, that one's fairly easy too, though a little verbose
# [01:53] <hyatt> i think it's insane
# [01:53] <hyatt> i think this whole section should be scrapped
# [01:53] <zcorpan_> oh? i think it's quite useful
# [01:53] <hyatt> i mean i think it should be redone
# [01:53] <zcorpan_> why?
# [01:54] <hyatt> it doesn't bind to a data model
# [01:54] <hyatt> that to me is the most compelling way to use a feature like this
# [01:54] <hyatt> it should be more like XUL templates
# [01:54] <hyatt> or Xforms
# [01:55] <Hixie> hyatt: hey
# [01:55] <Hixie> yeah, i don't like the repetition model either
# [01:55] <hyatt> but maybe i'm misunderstanding the use case
# [01:55] <Zeros> ugh, USP Prober causes a KP.
# [01:55] <Hixie> but i couldn't find another way of doing it that would gracefully degrade in legacy UAs
# [01:55] <Zeros> hyatt, oh, thanks for fixing that bug so quickly :)
# [01:56] * Hixie would be ok with scrapping it, but doesn't know what to replace it with
# [01:56] <Hixie> (if anything)
# [01:57] <hyatt> XUL templates
# [01:57] <hyatt> or something closer to them
# [01:57] <hyatt> IMO :)
# [01:57] <Hixie> those aren't even remotely compatible with legacy UAs
# [01:57] <Hixie> e.g. you can't have the server "fake" the repetition implementation the way you can with the wf2 version
# [01:58] <Zeros> Hixie, I don't like the overloaded repeat attribute
# [01:58] <Zeros> Too many valid values, its confusing.
# [01:58] <Hixie> repeat="template" vs repeat="0", you mean?
# [01:58] <Hixie> it only takes a number or a keyword.
# [01:58] <Zeros> Yes
# [01:59] <Hixie> that's only one more allowed value than the value="" attribute on the <li> element
# [01:59] <mjs> I don't love the repetition model either, but I'm not sure a repetition model is very useful for forms as actually commonly used on the web
# [01:59] <Zeros> I'd not mix the two types. If you need a way to be a template add a repeat-template attribute or some such
# [01:59] <Hixie> Zeros: there were detailed discussions which culminated into the current model, i'd have to look into them again to recall why we designed it this way
# [01:59] <Hixie> but yeah, i'm more inclined to just drop it altogether
# [01:59] <Zeros> Hixie, I think its going to be very confusing to new users
# [01:59] <Hixie> i do not disagree
# [02:00] <Zeros> Having the allowed values be either a number or a string is not something I'd do
# [02:00] <Hixie> Zeros: i understand
# [02:00] <Zeros> If you find out why you chose it let me know, maybe there was a good reason.
# [02:01] <Philip`> It doesn't seem confusing to me if I just copy and tweak the example (unless I'm missing some subtle issues, which is quite possible)
# [02:01] <Hixie> zeros: i don't especially intend to look into it any time soon, but if we end up discussing it it's certainly something i'd look into
# [02:01] <Zeros> okay
# [02:01] <Zeros> I'll bring it up when we start bring over HTML5 and web forms then
# [02:02] <Hixie> when we were doing the later stages of cleanup on wf2, and removing features, the repetition model was the very next feature on the cutting block before we stopped dropping features
# [02:03] <Hixie> fwiw
# [02:04] <Zeros> What's the purpose of the value attribute on li?
# [02:05] <Zeros> "The value attribute, if present, must be a valid integer giving the ordinal value of the first list item." isn't that what start is for?
# [02:06] <Zeros> oh
# [02:06] <Hixie> start gives the value of the first item
# [02:07] <Zeros> Hixie, that's another one that needs cleaning up in the text. The li attribute desc. says it gives the value of the first list item, but the text for the ol says it's the index value of the element
# [02:07] <Zeros> The description of what value does under <ol> is much more clear
# [02:08] <Zeros> "Each subsequent item in the list has the ordinal value given by its value attribute, if it has one, or, if it doesn't, the ordinal value of the previous item, plus one."
# [02:08] * Parts: hasather (hasather@81.235.209.174)
# [02:09] <Hixie> oops
# [02:09] <Hixie> can you said me a mail about that?
# [02:09] <Hixie> i'll fix it when i next work on lists
# [02:09] <Zeros> sure
# [02:09] <Hixie> ian@hixie.ch or if you're on the whatwg list whatwg@whatwg.org
# [02:09] <Hixie> thanks
# [02:09] <Zeros> np
# [02:11] <hyatt> maybe i am conflating xul templates with this feature i dunno
# [02:12] <hyatt> but if i am going to auto-generate some giant tree view or table or list or menu
# [02:12] <hyatt> i want to be able to bind a template to a back-end model DOM
# [02:12] <Hixie> hyatt: i agree entirely with your e-mail, except for one thing -- i can't see how to do it with legacy UAs able to handle the new markup sanely.
# [02:13] <hyatt> which part?
# [02:13] <Hixie> whole thing
# [02:13] <hyatt> it's not clear to me that this particular feature has to degrade gracefully
# [02:13] <Hixie> the wf2 repetition model actually works in legacy browsers (with some server side support)
# [02:13] * Joins: schepers (schepers@66.26.56.91)
# [02:13] <hyatt> really?
# [02:13] <Hixie> yeah
# [02:13] <Hixie> http://www.whatwg.org/demos/repeat-01/
# [02:13] <Hixie> try it in safari
# [02:15] <hyatt> hmmm what makes yo usay that my proposal wouldn't degrade gracefully the same way?
# [02:15] <hyatt> legacy browsers would fail to bind to the model
# [02:15] <hyatt> and would render the template
# [02:15] <hyatt> the buttons could still be hacked ...
# [02:15] <hyatt> so seems like i'm not proposing anything that couldn't still work in legacy UAs
# [02:15] <Hixie> well i'm certainly open to that kind of thing
# [02:16] <hyatt> anyway i think this feature transcends forms the way i'm proposing it
# [02:16] <Hixie> i just haven't been able to come up with a design myself
# [02:16] <Hixie> i agree that it's not a form thing
# [02:16] <Hixie> and i'd love to drop the repetition model
# [02:16] <Hixie> in favour of something better
# [02:16] <hyatt> cool
# [02:17] <hyatt> this kind of ties in with datagrid too
# [02:17] <hyatt> since it has the concept of binding to a back end right
# [02:17] <Hixie> yeah
# [02:17] <Hixie> <datagrid> binds to a JS-provided or markup-backed tree structure.
# [02:17] <hyatt> maybe i can draft something in my copious spare time
# [02:17] <hyatt> hahah
# [02:17] <Hixie> heh
# [02:17] <Hixie> we need to have lunch with a whiteboard one of these days
# [02:17] <Hixie> and hash something out
# [02:19] <hyatt> yeah
# [02:20] <Zeros> Hixie, the repeat model doesn't degrade nicely though. <button> won't submit without your JS back in IE and the known types on <input> cause a text field.
# [02:20] <Zeros> unknown*
# [02:20] <hyatt> to me repetition model is one of those major shifts that may not be backwards compatible
# [02:20] <hyatt> it's not like datagrid will degrade right
# [02:20] <Hixie> Zeros: yeah, it only works in legacy html4-compliant UAs, sadly. one more reason i'm not a big fan of it.
# [02:20] <hyatt> i think we should strive for degradability as much as possible
# [02:20] <hyatt> but not 100%
# [02:21] <Hixie> hyatt: well, if the data backing your datagrid is a markup <table>, then yes, it will (it'll degrade to a table)
# [02:21] <hyatt> if the feature is compelling enough
# [02:21] <Hixie> hyatt: but if the data backing your datagrid is a JS component, then you'll need more JS to make it degrade.
# [02:21] <hyatt> Hixie: ah, is the model forced to be inside the datagrid or something?
# [02:21] <Zeros> I agree with hyatt, but I think there needs to be a better way than the repetition model.
# [02:22] <Zeros> repeat-action="delete" would have been a better solution since it would allow <input type="submit"
# [02:22] <Zeros> Then we get IE support
# [02:22] <Hixie> hyatt: you have four or so choices, iirc -- it can be an explict JS component that does whatever you want, or there can be some markup that fits a particular set of rules
# [02:22] <Hixie> hyatt: one of the rules is basically a <table>
# [02:22] <Hixie> Zeros: hyatt and i are in agreement here
# [02:23] <Zeros> :)
# [02:23] <Zeros> Hixie, So are you going to reconsider it?
# [02:24] <Hixie> hyatt: so looking at the definition, the <datagrid> can be backed by a <table>, a <select>, a list (<ol>, <ul>)
# [02:24] <Hixie> hyatt: and it'll generate the right data grid out of it (with the right context menus, etc)
# [02:24] <Hixie> Zeros: everything in the whole spec is always up for reconsideration, especially when someone points out a better solution as hyatt is doing
# [02:24] <Zeros> alright
# [02:25] <hyatt> Hixie: i think this points to a way to degrade as well
# [02:25] <hyatt> imagine something like <datagrid>
# [02:26] <hyatt> but that is independent of a particular widget
# [02:26] <hyatt> e.g., <repeat> that does what datagrid does
# [02:26] <hyatt> and that can bind to these degradable models
# [02:26] <Hixie> hyatt: yeah... yeah! this could work
# [02:26] * Hixie starts drawing on his whiteboard
# [02:27] <Hixie> i wonder how we can do nested repeats
# [02:27] <hyatt> models nest in certain forms (like lists)
# [02:27] <hyatt> but yeah
# [02:27] <Zeros> Can't you just spawn a new repeat context?
# [02:29] <hyatt> ok gotta head home
# [02:29] <hyatt> will be on later
# [02:29] * Quits: hyatt (hyatt@17.255.99.164) (Quit: hyatt)
# [02:29] * Quits: schepers (schepers@66.26.56.91) (Connection reset by peer)
# [02:29] * Joins: schepers (schepers@66.26.56.91)
# [02:32] <Zeros> Hixie, Maybe reconsider the way to substitute in values in attributes as well
# [02:37] <Hixie> if we go down the road hyatt suggested, the whole thing would be redone entirely
# [02:39] <Zeros> okay
# [02:39] <Zeros> Oh, and someone already mailed the whatwg list about the li attribute
# [02:40] <Hixie> cool
# [02:47] * Joins: htmlr (htmlr@203.217.80.229)
# [02:51] * Joins: sbuluf (esiwdu@200.49.140.176)
# [02:51] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Ping timeout)
# [03:03] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [03:06] * Quits: Zoffix (Zoffix@99.244.41.243) (Ping timeout)
# [03:14] * Joins: Zoffix (Zoffix@99.244.41.243)
# [03:35] * Joins: marcos (chatzilla@131.181.148.226)
# [03:40] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [03:45] * Joins: gavin_ (gavin@74.103.208.221)
# [03:48] * Quits: mjs (mjs@17.255.99.9) (Quit: mjs)
# [03:56] * Quits: schepers (schepers@66.26.56.91) (Quit: Free at last!)
# [04:03] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [05:18] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [05:25] * Quits: EricPuidokas (eric@65.34.6.69) (Ping timeout)
# [05:26] * Joins: mjs (mjs@66.245.248.74)
# [05:38] * Joins: dbaron (dbaron@71.198.189.81)
# [05:51] * Quits: mjs (mjs@66.245.248.74) (Quit: mjs)
# [05:51] * Joins: hyatt (hyatt@24.6.91.161)
# [05:52] * Joins: mjs (mjs@66.245.248.74)
# [05:55] * Quits: mjs (mjs@66.245.248.74) (Ping timeout)
# [05:56] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:01] * Joins: schepers (schepers@69.134.24.226)
# [06:06] <Hixie> hyatt: to answer the question you just mailed to public-html, the repetition model integrates with the form submission stuff
# [06:07] <Hixie> that's why it's in wf2 and not wa1
# [06:07] <Hixie> however, note that there is a section for it in the wa1 spec already, i just haven't moved the stuff over
# [06:07] <Hixie> (since we might just drop it)
# [06:08] <schepers> Hixie: (sorry, should consult the spec, but I've been busy) have you made any more consistent APIs for accessing form elements? I'm referring to the screwy way you get/set values on radio buttons, for example
# [06:09] <schepers> s/the screwy way you get/the screwy way one has to get/
# [06:13] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [06:14] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [06:18] <hyatt> Hixie: ah ok
# [06:23] <hyatt> Hixie: i have honestly only skimmed the repetition model section
# [06:23] * Joins: mjs (mjs@64.81.48.145)
# [06:23] <hyatt> which was one reason i was being quiet during all the forms debating
# [06:24] <hyatt> :)
# [06:24] <mjs> hello all
# [06:26] <hyatt> hey mjs
# [06:26] <mjs> hello hyatt
# [06:26] <mjs> hyatt: so was I really that mean to John_Boyer?
# [06:26] <hyatt> you have not been mean
# [06:27] <hyatt> i think now that technical specifics have actually been mentioned, that this discussion got much better
# [06:27] * Joins: kazuhito (kazuhito@210.232.34.13)
# [06:27] <mjs> I didn't think so, but I try to double-check in such cases
# [06:27] <hyatt> there's been too much hand-wringing without meaty technical details
# [06:27] <hyatt> thats why i enjoyed finally seeing a real criticism (e.g., the repetition model)
# [06:27] <hyatt> thats how progress will get made
# [06:27] <Hixie> schepers: some, not for radio buttons as i recall, though.
# [06:28] <schepers> that's something I'd really like to see, though I haven't thought of how to degrade it in older browsers
# [06:29] <mjs> hyatt: I thought even the list of requirements was really helpful
# [06:29] <hyatt> yeah
# [06:29] <mjs> before I very literally did not know what the XForms contingent wanted
# [06:30] <mjs> I thought their main goal was a declarative expression language of some kind, but that doesn't seem to have made their top 10 requirements
# [06:34] <schepers> I think that would make Raggett's top 10
# [06:34] <schepers> but I'm guessing
# [06:36] <mjs> yeah, I assumed his view was in step w/ the rest of the Forms WG
# [06:37] <schepers> no idea, I just know he really likes declarative solutions
# [06:39] <zcorpan_> hyatt, mjs: have you seen http://bugs.webkit.org/show_bug.cgi?id=13568 ?
# [06:41] <mjs> zcorpan_: now I have
# [06:41] <hyatt> zcorpan_: yes i've seen it
# [06:41] <hyatt> zcorpan_: not going to move on it though until a decision has been reached
# [06:42] <hyatt> but at this time i don't think we should change it
# [06:42] <zcorpan_> hyatt: the csswg said they won't change the spec unless implementors do this
# [06:43] <zcorpan_> hyatt: currently there isn't interop
# [06:43] <hyatt> i believe we are pretty close to ffx
# [06:43] <hyatt> in our behavior
# [06:43] <mjs> hyatt: per the firefox bug, we seem to be the only ones following the spec
# [06:43] <mjs> er
# [06:43] <zcorpan_> hyatt: for background, yes. for overflow, no
# [06:44] <mjs> per the mozilla bug
# [06:44] <hyatt> mjs: yeah thats because i read the spec when i implemented this
# [06:44] <hyatt> i read the spec when doing overflow :)
# [06:44] <mjs> Mozilla and Opera both fail to match in one way or another
# [06:44] <hyatt> anyway i'd need more technical details
# [06:44] <hyatt> before proceeding
# [06:45] <hyatt> since even with <body> quirks vs.. strict has it doing very different things in html
# [06:45] <mjs> of course, CSS WG also wants to make table layout different between HTML and XHTML, which would make this difference trivial by comparison
# [06:45] <hyatt> for example <body> fills the viewport in quirks mode
# [06:45] <hyatt> but it doesn't do that in strict mode
# [06:45] <hyatt> which makes applying the overflow of the <body> to the viewport kind of crazy
# [06:45] <hyatt> we even still do that in html strict mode
# [06:45] <hyatt> which is bizarre
# [06:46] <zcorpan_> hyatt: you wouldn't like to have the css spec say that html and xhtml should be treated the same wrt background and overflow (in strict mode)?
# [06:46] <mjs> are background-color and background-image supposed to be different between HTML strict mode and XHTML?
# [06:46] <hyatt> i think the whole thing is screwed up right now
# [06:46] <hyatt> i think body should be mandated to fill the viewport
# [06:46] <hyatt> and then yes i would be fine with consistency
# [06:46] <zcorpan_> mjs: per the current spec, yes
# [06:46] <mjs> zcorpan_: what's the difference?
# [06:47] <zcorpan_> mjs: when the root element has a transparent background-color and no background-image, the background for body applies to the canvas and no background is rendered on the body element
# [06:47] <hyatt> i believe we do propagate the background up even in xml
# [06:48] <hyatt> don't we?
# [06:48] <zcorpan_> hyatt: root->canvas, yes
# [06:48] <mjs> so in strict you propagate the background up, but the body doesn't fill the viewport?
# [06:48] <zcorpan_> mjs: exactly
# [06:49] <hyatt> no i don't think that's it
# [06:49] <hyatt> body doesn't fill the viewport even in html strict mode
# [06:49] <mjs> I wish there was just some CSS property that said "this element fills the viewport if otherwise it would be smaller
# [06:49] <hyatt> mjs: this is all stupid
# [06:49] <mjs> then we could say it applies to the body and there'd be no special case
# [06:49] <hyatt> mjs: everything should just be fixed to be like quirks mode
# [06:49] <zcorpan_> i still have speccing quirks mode on my todo list
# [06:50] <hyatt> mjs: the real error here is in making <html> and <head> able to have any rendering at all
# [06:50] <hyatt> it's silly
# [06:50] <hyatt> <body> should just function as the root
# [06:50] <hyatt> and fill the viewport
# [06:50] <hyatt> that's effectively the sensible behavior
# [06:50] <hyatt> web authors don't understand having to throw percentage heights on the body and crap just to try to fill the viewport in strict mode
# [06:50] <hyatt> it's one of the main reasons people stay in quirks mode
# [06:50] <hyatt> the whole situation is a gigantic mess
# [06:51] <hyatt> instead we get crazy behavior like a tiny body element being allowed to set overflow on the whole viewport
# [06:51] <mjs> there's ways to achieve this by defining some appropriate CSS property that would be set in html4.css by browsers is what I'm saying
# [06:51] <mjs> then you don't need an HTML-specific special case
# [06:51] <hyatt> you shouldn't have to though
# [06:51] <mjs> and the desire to be different from XHTML goes away
# [06:51] <zcorpan_> hyatt: i don't disagree, but i think going back to quirks mode behavior for this now would break some pages
# [06:51] <hyatt> i doubt it, since WinIE's body always fills the viewport
# [06:51] <hyatt> even in strict mode
# [06:52] <hyatt> unless you mean xml pages
# [06:52] <hyatt> in which case the 8 people authoring xml on the web can update their pages
# [06:52] <hyatt> ;)
# [06:52] <zcorpan_> hyatt: no it doesn't, you can apply a border to body in ie and it won't be around the entire viewport
# [06:53] <zcorpan_> in html strict
# [06:53] <hyatt> ah
# [06:53] <hyatt> ok didn't know they did that in strict mode
# [06:53] <hyatt> is that new in ie7
# [06:53] <hyatt> or does ie6 work that way
# [06:53] <zcorpan_> no, ie6
# [06:53] <hyatt> ah ok then i guess we can't change it
# [06:53] <zcorpan_> indeed
# [06:54] <zcorpan_> but we can make xhtml be the same as html strict
# [06:54] <hyatt> sure, would need to know the differences though
# [06:54] <hyatt> i know overflow is one
# [06:54] <hyatt> i thought our background code was identical though
# [06:54] <hyatt> i don't recall having an htmldocument check in that code
# [06:54] <zcorpan_> identical to what?
# [06:54] <hyatt> to html strict
# [06:54] <hyatt> xml and html strict should be the same
# [06:54] <hyatt> for background propagation
# [06:54] <hyatt> in ToT WebKit
# [06:55] <zcorpan_> not according to the results i got (though i didn't test myself, the results could be wrong)
# [06:55] <zcorpan_> i think the test cases should cover all cases
# [06:55] <zcorpan_> you just need to implement what the spec says you should do for html, but also for xhtml
# [06:56] <hyatt> and i'm saying that aside from overflow i think we already do
# [06:56] <hyatt> but i could double check
# [06:56] <zcorpan_> ok
# [06:57] <zcorpan_> (if so, then you'd be more like opera than gecko)
# [06:57] <hyatt> ah nvm
# [06:57] <hyatt> i see an ishtmldocument check.
# [06:57] <hyatt> it's actually not even intentional
# [06:57] <hyatt> it was just to call document()->body()
# [06:57] <hyatt> hah
# [06:58] <zcorpan_> :)
# [06:58] <hyatt> but document.body is now defined on XML docs
# [06:58] <hyatt> since it had to be because the dom test suite relied on it
# [06:58] <hyatt> so that cast isn't needed now
# [06:58] <zcorpan_> ah, my tests rely on document.body too
# [06:59] <hyatt> ah nvm there's another isHTMLDocument check
# [07:00] <hyatt> yeah i guess i did this on purpose
# [07:00] <hyatt> probably read a spec or something!
# [07:00] <hyatt> :)
# [07:00] <zcorpan_> probably :)
# [07:00] <hyatt> it's an easy patch
# [07:00] <hyatt> just 3 places where isHTMLDocument() is used as a guard
# [07:01] <Zeros> What's TOT stand for?
# [07:01] <hyatt> oh sorry, "Tip of Tree"
# [07:01] <hyatt> our current code
# [07:01] <Zeros> yeah, just wasn't sure what the letter really meant
# [07:02] <hyatt> zcorpan_: are you simon pieters?
# [07:03] <hyatt> ah i see that you are
# [07:03] <hyatt> you people and your "Z" names. confusing me!
# [07:03] <zcorpan_> hyatt: yes :)
# [07:04] <hyatt> i'm a little bit nervous changing to not match ffx
# [07:04] <hyatt> since of course people will just blame us
# [07:04] <hyatt> they always do
# [07:04] <hyatt> :)
# [07:04] <zcorpan_> hyatt: you chould change overflow
# [07:04] <hyatt> since ffx = standards mode
# [07:04] <zcorpan_> hyatt: gecko passes all overflow tests
# [07:05] <Zeros> hyatt, nothing wrong with not matching ffx you just need to convince the gecko developers to match you
# [07:05] <hyatt> so basically we match the current spec the most closely right now
# [07:05] <zcorpan_> hyatt: yes
# [07:06] <hyatt> that'll teach me to trust specs
# [07:06] <zcorpan_> hyatt: but you still have bugs in some edge cases
# [07:06] <hyatt> probably background-position and repeat and stuff
# [07:06] <hyatt> we don't do any of that right
# [07:06] <hyatt> in the case where the body is smaller than the viewport
# [07:06] <zcorpan_> yeah, that's one
# [07:06] <Zeros> At least the background-repeat when the element was too small bug is fixed! :)
# [07:06] <hyatt> but we support multiple backgrounds so that makes up for it
# [07:07] <zcorpan_> :)
# [07:10] <zcorpan_> hyatt: also, changing this would only affect xhtml pages. since you accept */* you don't receive xhtml pages even when authors do this funny content negotiation thing
# [07:10] <zcorpan_> and even if they do they probably style the root element, so it wouldn't affect them
# [07:10] <mjs> zcorpan_: in current nightlies, we send application/xhtml+xml in our Accept header
# [07:11] <zcorpan_> mjs: ok
# [07:11] <mjs> but that does make it unlikely that anyone was depending on our old XHTML rules
# [07:11] <zcorpan_> indeed
# [07:13] <Zeros> Current Safari has issues with entities though. I've talked to a lot of developers about adding special checks to avoid */* matching Safari, sometimes it wasn't better to get the xml version
# [07:14] <mjs> I think nightlies have the entity stuff fixed
# [07:14] <hyatt> we fixed most entity problems
# [07:14] <hyatt> safari 2 has broken entities
# [07:14] <hyatt> but ToT does not
# [07:15] <zcorpan_> do you parse the internal subset?
# [07:15] <hyatt> Safari 2 = 2 years old
# [07:15] <hyatt> WebKit = very different
# [07:16] <zcorpan_> (safari 2 doesn't parse the internal subset in xml iirc, or at least entities declared in it don't work)
# [07:16] <Zeros> hyatt, yeah, the nightlies are much better
# [07:17] <Zeros> Any chance we can get a way to turn off CSS?
# [07:17] <Zeros> There's a way to disable JS, Plugins, Java and everything but
# [07:18] <mjs> I'm not sure if we support the internal subset
# [07:18] <hyatt> yeah problem is there's no security argument for turning off css
# [07:18] <mjs> but we did fix other common entity issues
# [07:18] <hyatt> turning off css is really a web developer sort of feature
# [07:18] <Zeros> hyatt, Stick it in the debug menu then?
# [07:18] <hyatt> could maybe put it in the debug menu
# [07:18] <hyatt> or teach our web inspector how to do it
# [07:18] <mjs> Zeros: you can turn off CSS by putting a value of "initial !important" for every CSS property in your user stylesheet
# [07:19] <hyatt> mjs: not true
# [07:19] <hyatt> style="..."
# [07:19] <hyatt> and all of the mapped attributes
# [07:19] <mjs> hyatt: style="" would override !important rules?
# [07:19] <zcorpan_> they shouldn't...
# [07:19] <mjs> (I don't think so)
# [07:19] <Zeros> I'd love if the web inspector had inputs to mutate the DOM
# [07:19] <mjs> I don't know about mapped attributes, I assume not in that case either
# [07:19] <hyatt> yeah mapped attributes would lose to a user important rule
# [07:20] <hyatt> yeah i guess that would work
# [07:20] <Zeros> mjs, that's a bit overkill for something that shouldn't be so complicated. Safari caches the user stylesheet too. you have to restart with changes I think
# [07:20] <hyatt> correct
# [07:21] <hyatt> actually no
# [07:21] <mjs> Zeros: well, I'm thinking of it as an expert feature, thus the expert way to do it - if you can explain how it is useful as an end-user feature or a broadly applicable developer feature we can consider it
# [07:21] <hyatt> mjs: i am not sure disable CSS means "turn off the UA sheet"
# [07:21] <Zeros> hyatt, that's interface is little counter intuitive btw. There's a select menu, but it only ever stores a single stylesheet and none.
# [07:21] <hyatt> mjs: i think it means turn off author and user
# [07:21] <Zeros> is a*
# [07:21] <hyatt> mjs: so actually i don't think you can do it from the user sheet
# [07:22] <hyatt> disable CSS really means "turn off all author CSS"
# [07:22] <Zeros> yeah
# [07:22] <Zeros> hyatt, might be nice if it had more so you could select between minimal and high contrast or whatever sheets you wanted
# [07:22] <mjs> yeah, no simple way to do that
# [07:22] <hyatt> it's very simple to do that with a code patch
# [07:22] <hyatt> but yeah no way to do it with safari 2 i think from the user sheet
# [07:23] <Zeros> There's also #5 of the CSS conformance rules that Safari doesn't follow
# [07:24] <Zeros> "If the source document comes with alternate style sheets (such as with the "alternate" keyword in HTML 4.0 [HTML40]), the UA must allow the user to select one from among these style sheets and apply the selected one."
# [07:24] <Zeros> Which is where Firefox and Opera expose the No CSS option as well.
# [07:25] <Zeros> Is there a problem with adding that to the View menu in the same manner?
# [07:25] * Quits: schepers (schepers@69.134.24.226) (Quit: Free at last!)
# [07:25] <mjs> Zeros: it's inappropriate for the spec to demand fiddly expert-level UI features
# [07:26] <mjs> (it is possible to select from alternate stylesheets via javascript: URLs or under control of script in the page though)
# [07:26] <Zeros> that doesn't work if you have JS disabled on the page
# [07:26] * Joins: schepers (schepers@69.134.24.226)
# [07:26] <Zeros> mjs, from the same argument you could say Safari doesn't need font +/- options since JS can do that too
# [07:27] <hyatt> Zeros: a bookmarklet is considered conformant btw
# [07:27] <Zeros> Both Opera and Firefox expose the alternate stylehsheet options though
# [07:27] <mjs> Zeros: we have those because of perceived need for typical end-users
# [07:27] <hyatt> Zeros: this came up with Mac IE and tasman
# [07:27] <hyatt> Zeros: and a bookmarklet in the bookmarks bar was ruled as being conformant
# [07:27] <Zeros> hyatt, really? interesting
# [07:27] <mjs> we lack a lot of prefs that other browsers have in the UI
# [07:28] <hyatt> Zeros: my main reasoning behind not exposing alternate stylesheet UI
# [07:28] <hyatt> Zeros: is that it needs to be implemented well before exposing it
# [07:28] <hyatt> and implementing it well is hard
# [07:28] <Zeros> mjs, I know, and most of them I don't think matter. However I do think its poor form to hide those options entirely, there isn't anything letting a user know they even exist
# [07:28] <hyatt> a crappy "you have to click this for every page in the domain" rule is no good
# [07:28] <hyatt> not remembering choices is no good
# [07:28] <Zeros> hyatt, Okay, that's a good argument. Better done right than poorly for the sake of adding it
# [07:28] <hyatt> right
# [07:28] <hyatt> and doing it right is pretty hard
# [07:29] <zcorpan_> i think konq remembers the choise
# [07:29] <hyatt> it's also tricky to do it in such a way that doesn't conflict with the site's own fiddly cookie-setting stuff
# [07:29] <Zeros> plist with the domain I guess
# [07:29] <mjs> and of marginal value for most people
# [07:30] <hyatt> it's funny too because browsers tend to be so buggy at changing stylesheets dynamically
# [07:30] <hyatt> that people just use the server to do the switching often anyway
# [07:30] <Zeros> Well, I'd settle for a disable user stylesheets option in the debug menu at this point.
# [07:30] * Quits: heycam (cam@124.168.141.224) (Ping timeout)
# [07:30] <hyatt> user?
# [07:30] <Zeros> err author
# [07:30] <hyatt> you mean author?
# [07:30] <hyatt> heh
# [07:30] <Zeros> yes
# [07:31] <hyatt> we have a big desire to beef up our development tools
# [07:31] <hyatt> and turning off css fits naturally into that
# [07:31] <Zeros> hyatt, Have you ever looked at Shiira?
# [07:31] <hyatt> Zeros: haven't looked at 2.0 yet
# [07:31] <hyatt> did look at < 2.0
# [07:31] <Zeros> The interface is nicely done.
# [07:31] <hyatt> it's very unpolished though
# [07:31] <hyatt> some good ideas though
# [07:32] <Zeros> yeah
# [07:32] <hyatt> has the feel of being like 80% finished
# [07:32] <Zeros> Sunrise also has a very cool feature that lets you edit code right in the source view and see changes
# [07:32] <hyatt> yeah i love that
# [07:32] <hyatt> big fan of that
# [07:32] <Zeros> me too
# [07:33] <zcorpan_> opera has that too
# [07:35] <Zeros> hmm, the user agent list doesn't let you go back to automatically chosen
# [07:38] <hyatt> yay i compiled
# [07:38] <hyatt> boo i didn't link
# [07:42] <Zeros> heh, Shiira has the Exposé tabs that karl was asking for
# [07:46] * Joins: heycam (cam@203.214.12.71)
# [08:11] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [08:15] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [08:16] * Joins: gavin_ (gavin@74.103.208.221)
# [08:59] * Quits: kazuhito (kazuhito@210.232.34.13) (Quit: Quitting!)
# [09:07] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [09:22] * Quits: marcos (chatzilla@131.181.148.226) (Connection reset by peer)
# [09:24] * Joins: tH (r@87.102.32.222)
# [09:31] <anne> lots of e-mails...
# [09:32] * Quits: sbuluf (esiwdu@200.49.140.176) (Ping timeout)
# [09:38] <anne> "*snork* Come on, man, not while I'm eating lunch." heh
# [09:44] * anne is arrives at charter discussions
# [09:47] * Quits: loic (loic@90.29.109.153) (Ping timeout)
# [09:49] <mjs> anne: I didn't think it was that funny, but I'm glad Chris has a sense of humor about it. :-)
# [09:50] <anne> As long as XHTML is draconian I don't really care about it
# [09:50] <anne> Fortunately the holy mobile world is helping is out there :)
# [09:51] <anne> s/is out/us out/
# [09:51] <mjs> it has value in providing a draconian path for those who want one
# [09:51] <mjs> though apparently some will be unsatisfied until all available options are draconian
# [09:51] <anne> It's just for the syntax. I don't see much value in just doing it for the syntax.
# [09:52] <mjs> that is true, surface-level syntactic checking is some of the less interesting automated checking you could do
# [09:52] <anne> Maybe if it was like Silverlight it would work. But you can no longer introduce such a thing on top of XML
# [09:52] <anne> And it would hurt extensibility etc. a lot.
# [09:53] * Joins: zdenko (zdenko@193.77.152.244)
# [09:54] <mjs> anne: I think the most entertaining thread is John Boyer's with me
# [09:54] * Quits: MrNaz (Naz@203.214.95.166) (Ping timeout)
# [09:54] <anne> Yeah, your charter citations were nice
# [09:55] <mjs> well, mainly it was his parts that I found entertaining
# [09:56] * zcorpan_ points out that the html5 parsing spec allows for drocanian error handling too
# [09:56] <anne> oh right
# [09:56] <anne> yeah, XML5 would too
# [09:57] <mjs> zcorpan_: the error handling in the HTML5 serialization isn't required for conformance?
# [09:57] <zcorpan_> mjs: you must either do as described or abort when you don't want to do as described
# [09:58] <mjs> interesting
# [09:58] <zcorpan_> mjs: strictly speaking you may also do whatever you want for pages that don't start with the new doctype
# [09:58] <schepers> that is odd
# [09:58] <schepers> I noticed that as well
# [09:59] <zcorpan_> "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."
# [10:00] <anne> The thing is that we do the latter we won't be used.
# [10:00] <mjs> I wonder why it's written that way
# [10:00] <anne> Where for a conformance checker it might be reasonable (thought not desirable)
# [10:00] <anne> if we do the latter*
# [10:00] <zcorpan_> 8.2.4.1. The initial phase...: (not starting with correct doctype) "This specification does not define how to handle this case. "
# [10:00] <mjs> I could almost consider either following the rules or aborting on *any* error to be reasonable
# [10:01] <mjs> but this effectively makes a large set of possible error handling algorithms
# [10:01] <anne> mjs, the current conformance checker recovers from some errors
# [10:01] <anne> mjs, but not all
# [10:01] <xover> I wonder where this desire for draconian error handling comes from...
# [10:01] <anne> I don't know
# [10:01] * anne tries to get rid of it
# [10:01] <anne> Forbidding it doesn't make much sense to me though
# [10:02] <anne> mjs, it should probably be a requirement for user agents to always recover
# [10:02] <anne> mjs, well, at least for the class "web browsers" are in
# [10:02] <mjs> anne: well, a conformance checker seems like a pretty different case from browsers or data mining tools
# [10:02] <zcorpan_> xover: so you can browse well-formed pages with your mobile that can't afford to recover from parse errors... ;)
# [10:02] <anne> yeah, didn't you hear, the mobile web only does XHTML
# [10:02] <anne> and it works great
# [10:02] <anne> XML everywhere!
# [10:03] <mjs> for a conformance checker, flagging nonconforming content is the whole point, so failing in some cases of nonconformance seems ok, even when other content consumers would recover
# [10:03] <anne> but if it can recover that's ok as well, so it can point out more errors
# [10:03] <mjs> for tools that intend to process the data in a more meaningful way, it's unclear if that freedom has benefits
# [10:03] <mjs> right
# [10:04] <anne> yeah, I think I agree with you
# [10:04] <xover> For a conformance checker, bailing out at the forst error is certainly the least usefull option.
# [10:04] <zcorpan_> mjs: some tools that don't want to do buffering and can't change the tree afterwards would have to abort for the adoption agency thing
# [10:04] <zcorpan_> but they could still recover from other errors
# [10:04] <anne> good point
# [10:05] <anne> adoption agency sucks rocks
# [10:05] <mjs> I guess the algorithm guarantees you will either get the same success result as any other conforming implementation or abort
# [10:05] <schepers> you trying to adopt a kid, anne?
# [10:05] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [10:05] <anne> unfortunately it can't be changed in a way that would not require "weird things"
# [10:06] <anne> while remaining compatible
# [10:06] <mjs> adoption agency is the least weird way of addressing the compat issues I think
# [10:06] * Quits: zdenko (zdenko@193.77.152.244) (Quit: Ajl bi bak)
# [10:06] <zcorpan_> xml5 could do without it i presume? :)
# [10:06] <anne> yeah, xml5 has super simple error handling
# [10:06] <anne> explained it on #whatwg yesterday
# [10:06] <zcorpan_> oh, must have missed it
# [10:07] * mjs thinks we need CSS5 more than XML5 at this point
# [10:07] <anne> it's not actually in a spec yet or so, #whatwg is the only documentation i've got (besides my head)
# [10:07] <anne> mjs, I agree, but CSS5 is too big a research project for a semester
# [10:07] <mjs> fair enough
# [10:11] <zcorpan_> anne: how do you handle bogus namespace prefixes and bogus namespace declarations?
# [10:11] <anne> heh, the arguments from John Boyer are exactly what I would say about his position...
# [10:12] <anne> zcorpan_, what about them?
# [10:14] <zcorpan_> how is this document parsed? <foo:bar/>
# [10:14] <zcorpan_> is it element foo in namespace "" with namespace prefix bar?
# [10:15] <anne> I was thinking of {"", "foo:bar"}
# [10:15] <Hixie> mjs: for tools that don't need to interoperate with any random content, e.g. for tools in a processing pipeline at a publisher's, if their internal rules are "have no syntax errors!" then their tools need to be allowed to abort on syntax errors
# [10:15] <zcorpan_> ok. what about <foo xmlns:xmlns="bar"/> ?
# [10:16] <mjs> Hixie: yeah, the only part I'm unsure of is being allowed to do an arbitrary subset of the error handling
# [10:16] <mjs> that does seem useful for conformance checkers though
# [10:16] <Hixie> mjs: hsivonen requested it. basically there are something things -- e.g. the trailing / in some cases -- that are perfectly easy for him to handle. there are others -- like missing end tags -- that could mean anything, and if he doesn't stop there he might report any number of bogus errors.
# [10:17] <Hixie> in practice it doesn't matter much
# [10:17] <anne> zcorpan_, I would say that it sets the namespace prefix xmlns to namespace bar
# [10:17] * Joins: loic (loic@90.29.237.247)
# [10:18] <anne> unless there's some good reason to have xmlns reserved in which case it would be "ignored"
# [10:18] <anne> anyway, as you can tell this isn't worked out yet, but this has less to do with the actual tokenization I think
# [10:18] <zcorpan_> anne: that would make the all other namespace declarations stop working
# [10:18] <anne> unless I'm seriously missing something here
# [10:18] <anne> oh right, ignored
# [10:18] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [10:19] <xover> The most common complaint on www-validator is that it reports a gazillion "bogus" (cascading) errors in some cases.
# [10:19] <zcorpan_> anne: are attributes parsed the same way as in html5?
# [10:19] <zcorpan_> (but with more parse errors here and there?)
# [10:20] <zcorpan_> s/parsed/tokenized/
# [10:20] <anne> zcorpan_, yeah, not sure about more parse errors
# [10:21] <zcorpan_> anne: i thought it was a goal that any conforming xml5 document is also well-formed xml1.0?
# [10:21] <anne> no, the other way around
# [10:21] <zcorpan_> (perhaps ignoring text/xml and ascii)
# [10:21] <zcorpan_> oh
# [10:21] <zcorpan_> ok
# [10:22] <anne> same for xml1.1 hopefully
# [10:22] * xover wonders what “XML5” refers to here..
# [10:22] <mjs> it's Anne's idea for a dialect of XML with lenient error handling
# [10:22] <anne> XML without namespace well-formedness
# [10:23] <zcorpan_> i thought that if it would parse without errors in an xml5 parser, it would be safe to serve to xml 1.0 processors as well
# [10:23] <anne> zcorpan_, I don't think that's useful; I don't want to place weird restrictions on stuff like XML 1.0 / 1.1 does
# [10:24] * Joins: gavin_ (gavin@74.103.208.221)
# [10:24] <xover> anne: URL?
# [10:24] <anne> zcorpan_, as for "tools will safe us", conformance checkers can certainly indicate such boundaries
# [10:25] <anne> xover, there isn't much concrete yet
# [10:25] * anne is about to start
# [10:25] <zcorpan_> anne: hmm... ok. i'm not sure what i think about it yet
# [10:25] <anne> me neither
# [10:25] <anne> but for now I like this idea
# [10:27] <Hixie> i thinks tools are supposed to save us, not safe us
# [10:27] <Hixie> i don't think putting us into a safe would be helpful
# [10:27] <Hixie> :-)
# [10:27] <zcorpan_> it would mean that "xml pipe lines" would have to be updated if you updated to an xml5 parser, even if it was set up to be drocanian
# [10:27] <Hixie> though some might disagree...
# [10:28] * xover was just about to say... :-)
# [10:29] <xover> «Go on Hixie, get in there. There's a unconquered SGML bastion in there. Get in the darn safe!»
# [10:29] <zcorpan_> that's why xml 1.1 was ignored
# [10:29] <Hixie> no, xml 1.1 was ignored because if you write a well-formed xml 1.1 file, xml 1.0 parser say it's illformed
# [10:30] <zcorpan_> Hixie: anne suggested to do the same with xml5
# [10:30] <anne> no
# [10:30] <zcorpan_> now i'm confused
# [10:30] <anne> I specifically said that both well-formed XML 1.0 and XML 1.1 would still work in XML5
# [10:30] <Hixie> there's a difference between "every xml 5 file will be non-well-formed xml 1.0" and "some subset of xml 5 files will be well-formed xml 1.0"
# [10:30] <anne> and that two different subsets of XML5 therefore will work in XML 1.0 and 1.1
# [10:30] <Hixie> e.g. some HTML5 works as XML 1.0, even
# [10:30] <Hixie> but not all HTML5
# [10:31] <zcorpan_> anne: right. there should not be subsets, conforming xml5 should be well-formed xml 1.0
# [10:31] <anne> I don't think it makes sense to disallow XML 1.1 as XML5
# [10:31] <Hixie> anyway
# [10:31] <Hixie> gotta go
# [10:31] <Hixie> ttyl
# [10:32] <zcorpan_> xml 1.1 is already ignored, and not used, so i do think it makes sense :)
# [10:32] <anne> anyway, my project, my call
# [10:32] <anne> people can later fuck it up in some WG :p
# [10:32] <zcorpan_> anne: you should talk to hsivonen about this too :)
# [10:32] <anne> i did
# [10:33] <zcorpan_> he was ok with xml5 allowing things that are disallowed in xml 1.0?
# [10:33] <anne> i don't think he was (strongly) opposed, but dunno
# [10:35] <zcorpan_> Hixie said "xml 1.1 was ignored because if you write a well-formed xml 1.1 file, xml 1.0 parser say it's illformed"... wouldn't the same happen with xml5 if you did the same?
# [10:35] <zcorpan_> i'm just trying to help with xml5 becoming successful, i'm not working against you or anything :)
# [10:35] <anne> you can write backwards compatible HTML5 and you can write backwards incompatible HTML5
# [10:35] <zcorpan_> anne: difference with html5 is that existing parsers aren't drocanian
# [10:36] <zcorpan_> xml 1.0 parsers are
# [10:36] <anne> <map id>
# [10:36] * Joins: ROBOd (robod@86.34.246.154)
# [10:36] <zcorpan_> <map id> is something i've suggested to get changed to <map name> :)
# [10:37] <anne> glad you're being consistent
# [10:37] <zcorpan_> (which also allows authors to use <map name id> if they want to, which they might if they care about firefox 2.0 in xhtml)
# [10:37] <zcorpan_> am i not?
# [10:37] <anne> you are :)
# [10:37] <zcorpan_> phew :)
# [10:39] <zcorpan_> anyway, gotta go
# [10:43] * Joins: MrNaz (Naz@203.214.95.166)
# [10:44] <anne> see you
# [10:49] * Joins: AGraf|mb (Ashe@213.47.199.86)
# [10:50] * Parts: AGraf|mb (Ashe@213.47.199.86) (Leaving)
# [10:55] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [10:58] * Joins: zdenko (zdenko@193.77.152.244)
# [11:11] * Joins: edas (edaspet@88.191.34.123)
# [11:17] <anne> How hard is it to understand that if you want a UA to do something different with <b> than it does now you need a new format. Not an evolution of the format that contains <b>.
# [11:23] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [11:35] <Lachy> how hard is it for people to understand that a spec without normative requirements is just a list of feature requests?!
# [11:36] <anne> I think some people rather like HTML4
# [11:36] * Joins: beowulf (carisenda@91.84.50.132)
# [11:38] * gsnedders wonders what is going on now…
# [11:41] <anne> same as last week?
# [11:41] <gsnedders> I guessed
# [11:41] <gsnedders> [that]
# [11:41] <mjs> not quite the same
# [11:42] <mjs> people arguing against compatibility and error handling are gradually losing their resolve
# [11:42] <gsnedders> and saying they'll leave
# [11:42] <gsnedders> ergh. everyone will have to make compromises along the way
# [11:42] <mjs> one guy said that, but he hasn't left
# [11:43] <mjs> he seems unable to state an actual benefit for draconian error handling though
# [11:43] <gsnedders> I've seen othes
# [11:43] <gsnedders> two, I think
# [11:43] <mjs> other than mentioning that he likes "Segmentation Fault" messages
# [11:44] <gsnedders> but they're fun! you have to work out their cause!
# [11:44] <mjs> personally, I'd rather not bring the power and flexibility of segfaults to the web
# [11:44] <gsnedders> me neither
# [11:45] <beowulf> i wonder how many people asking for draconian error handling have ever written xhtml for a big organisation
# [11:46] <mjs> or at all
# [11:46] <gsnedders> As I've said before, I think all those criticising what browsers do, and implement, should write a browser themselves.
# [11:46] <gsnedders> Users _don't care_ why stuff doesn't work.
# [11:46] <gsnedders> They'll ask you to make it render, even if it is invalid.
# [11:47] <gsnedders> s/invalid/illformed
# [11:47] <mjs> it's a little glib to say if you don't like it, you should invest the hundreds of man-years needed to do your own
# [11:47] <mjs> but not entirely invalid
# [11:47] <gsnedders> I think they just really under-estimate the complexity of it
# [11:47] <anne> it's hard to grasp the complexity of the web not doing work related to some browser
# [11:47] <beowulf> I think some people are overly idealistic about html
# [11:48] <gsnedders> there are a few people with the vision of the XHTML2 WG, not the HTML WG
# [11:48] <beowulf> even aside from the browser complexity side of things (which i know nothing about)
# [11:48] <anne> (even then it stays hard :))
# [11:49] <beowulf> ignorance is bliss
# [11:50] <mjs> so the current vote on adopting HTML5 is 91-4-2
# [11:50] <mjs> (counting concur votes w/ the current majority)
# [11:50] <gsnedders> I haven't actually done anything about implementing an HTML renderer (nor CSS), but I understand the complexity (as well as direct knowledge of implementing things like HTTP and XML)
# [11:50] <beowulf> i was thinking, adopting html5 might have been better as something you had to sign up for in the charter :)
# [11:51] <mjs> one vote against the name HTML 5, stating that he'd prefer HTML 5.01 (not sure if this is a serious vote or if the voter understands that he is registering a Formal Objection)
# [11:52] <beowulf> I might change my vote to no, I'd prefer it to be HTML BEOWULF
# [11:52] <gsnedders> stating a preference isn't really a valid technical argument :)
# [11:52] * myakura wonders where does the .01 come from
# [11:52] <gsnedders> myakura: HTML 4.01
# [11:52] <mjs> only one vote against the editors
# [11:52] <mjs> w/ no argument
# [11:52] <gsnedders> (though HTML 4.0 predates HTML 4.01, so calling it HTML5.0 would be better under that argument)
# [11:53] <mjs> I think ~1% dissent is pretty good
# [11:53] <myakura> that explains :)
# [11:53] <beowulf> myakura: maybe they see the WHATWG HTML5 as preceeding W3C HTML5, i dunno
# [11:54] <mjs> John Boyer used the phrase "cut and run" in his comments
# [11:54] * gsnedders notices that Doug has changed his mind
# [11:54] <mjs> I wonder if he will advise us to "stay the course"?
# [11:55] <gsnedders> let me write something from an end user POV.
# [12:05] <gsnedders> of well. at least I have no further exams till Tuesday :\
# [12:11] <Lachy> I don't understand how people can argue that <sub> and <sup> are non-semantic.
# [12:12] <gsnedders> logic? we need that!?
# [12:13] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [12:13] <Lachy> I mean, it seems to be just an objection to the name because it has a presentational meaning
# [12:13] <Lachy> though, the names have semantic meanings too
# [12:15] * myakura checks how those elements are defined in HTML5
# [12:15] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [12:16] <beowulf> what are people suggesting <sub> and <sup> be replaced with?
# [12:17] <mjs> it appears that <sup> and <sub> have several possible semantics
# [12:17] <mjs> although meaning is likely to be altered more severely by removing them than removing <i> and <b>
# [12:19] <anne> I think having catch all elements for several typograhpical conventions is a good a thing
# [12:20] <mjs> me too
# [12:20] <mjs> it seems better than forcing use of <span> for everything
# [12:20] <anne> That such a typographical convention is used can be made clear in some media independent way and the user will know from the context what it was about.
# [12:20] <mjs> and better than inventing dozens of tags which might still not catch every case
# [12:21] * zcorpan_ notes that lynx renders 3<sup>2</sup> as 3^2
# [12:21] <anne> (Whether it was a mathematical formula or some chemical structure for instance. Or something like 2nd)
# [12:22] <myakura> but not LaTeX ;)
# [12:26] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [12:27] <anne> "Semantics" as used outside markup languages is clearly not appropriate for HTML. We'd have thousands if not millions of silly elements and nobody who will ever implement them properly or support them
# [12:28] <Dashiva> Maybe we need HyperTeX Markup Language for the semanticists?
# [12:28] <anne> they have XML
# [12:28] <anne> and classnames and such in HTML :)
# [12:28] <zcorpan_> and docbook
# [12:28] <anne> docbook doesn't go far enough I suppose
# [12:29] <zcorpan_> docbook+mathml? :)
# [12:29] <zcorpan_> +their own custom language? :)
# [12:29] <zcorpan_> let's just have custom languages!
# [12:29] <zcorpan_> then people can use whatever semantics they want
# [12:30] <Philip`> Some people seem to object that <sup> has too many possible meanings and a machine couldn't tell what you mean in a given context, but I think the value is that it indicates there's *some* kind of semantics and you can tell a human reader and they can work out what it means
# [12:30] <zcorpan_> and use xslt to convert it to html4 on the client side
# [12:31] <Philip`> whereas truly presentational elements don't have any meanings that a human could understand
# [12:31] * Joins: gavin_ (gavin@74.103.208.221)
# [12:31] <zcorpan_> Philip`: yeah, just like when you're reading from paper, the fact that it is superscript and the context is enough to figure out what it means
# [12:31] <Dashiva> I don't get how people can say <sup> is vague, while <em> isn't
# [12:32] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [12:35] <Philip`> If you wanted to write a web crawler that extracts mathematical expressions and evaluates them to analyse the frequency of miscalculations in published documents, then maybe you'd care about using some semantically-rich maths markup language; but I can't imagine many people doing that
# [12:36] <hsivonen> Philip`: I believe the use case for semantic math is that you could copy from the Web and paste into Mathematica
# [12:36] <Philip`> but I can imagine people with non-graphical browsers wanting to be told there's a difference between H^1 and H1, so they can know they have to use the context to work out what it means
# [12:36] <hsivonen> Philip`: the existing way is putting Mathematica code in alt=''
# [12:37] <hsivonen> of course, making this use case product-independent would make more sense if Mathematica has serious substitutes
# [12:37] <hsivonen> (I'm not familiar enough with Maple to know if it is a substitute)
# [12:38] <Philip`> Ah, okay
# [12:40] <beowulf> i don't get why anyone really cares about valid use of <em>, <i>, <b>, <strong>, <sup> or <sub>
# [12:40] <beowulf> or am i missing the point?
# [12:43] <hsivonen> beowulf: don't you see they are morally wrong?
# [12:43] <hsivonen> they being the elements
# [12:44] <hsivonen> (or perhaps I misunderstood the question)
# [12:44] <beowulf> i'm using the word morally as a clue to sarcasm, correct me if i'm wrong :)
# [12:44] <hsivonen> beowulf: no correction needed :-)
# [12:44] <beowulf> excellent :)
# [12:52] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [12:54] <Lachy> aargh! Now I'm just confused. Patrick H. Lauke has been arguing for increased semantics using as yet unspecified elements to replace <b> and <i>, yet he doesn't even understand the difference between <strong> and <em>
# [12:55] <gsnedders> according to HTML 4.01 there is no normative difference between all four :P
# [12:55] <Lachy> HTML4 is irrelevant
# [12:56] <Philip`> As far as I can see, it doesn't give a normative difference between <b> and <acronym> either
# [12:57] <Dashiva> That could be interesting in a debate
# [13:09] <mjs> Gareth Hay keeps saying he's leaving and ending the debate, but then he keeps debating
# [13:09] <mjs> I guess I should let him have the last word
# [13:11] <anne> ah, <HtML xmlNS=http://www.w3.org/1999/xhtml> is even cooler
# [13:11] * anne wonders why he didn't think of uppercasing some stuff before
# [13:18] <beowulf> make HTML l33t, <b0ldz0rz>
# [13:22] <Philip`> Pass it through CPP first, so you can "#define b0ldz0rz b" to get language extensibility
# [13:27] * anne hopes his post about technical motivation brings some sense in the discussion
# [13:32] <gsnedders> anne: sense?
# [13:34] <anne> "A capacity to appreciate or understand"
# [13:40] * gsnedders gives up with the constant missing of points on public-html, and revises Geography
# [13:41] <beowulf> i like schepers email from this morning
# [13:41] <anne> pointer?
# [13:41] <beowulf> geography bored me rigid
# [13:42] <beowulf> anne: http://www.w3.org/mid/463AF04F.1050608@vectoreal.com
# [13:43] <gsnedders> beowulf: I'm going to be sitting an exam on Tuesday having not completed the course :\
# [13:43] * gsnedders hides IRC to avoid constant distraction :)
# [13:43] <anne> does indeed make perfect sense
# [13:44] <beowulf> gsnedders: physical, human or both?
# [13:45] <gsnedders> beowulf: both
# [13:45] <gsnedders> (yeah, the hiding thing doesn't work with me)
# [13:45] <beowulf> :)
# [13:46] <gsnedders> beowulf: the physical stuff I can do very well, the human stuff not so
# [13:47] <beowulf> gsnedders: ditto
# [13:47] <beowulf> my degree was in geology
# [13:47] * gsnedders is nowhere near degree level in anything
# [13:47] <gsnedders> nor old enough to be
# [14:04] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [14:22] * Joins: hyatt (hyatt@24.6.91.161)
# [14:33] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [14:34] * Quits: MrNaz (Naz@203.214.95.166) (Quit: Leaving)
# [14:35] * Joins: MrNaz (Naz@203.214.95.166)
# [14:35] * Joins: cute (cute002@221.9.55.8)
# [14:36] * Parts: cute (cute002@221.9.55.8)
# [14:38] * Joins: gavin_ (gavin@74.103.208.221)
# [14:48] * zcorpan_ added specific test cases to http://bugs.webkit.org/show_bug.cgi?id=13568
# [15:02] <anne> yaiks
# [15:02] <anne> zcorpan_, any chance you can e-mail me a zipfile or your tests?
# [15:02] <anne> zcorpan_, or maybe just publish one online somewhere (just for css/magic-body, btw)
# [15:03] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [15:05] <zcorpan_> anne: all or just the ones you fail?
# [15:06] <zcorpan_> anne: can they be sent to the bug directly?
# [15:08] <zcorpan_> anne: btw, all 003s seem to expose a scripting bug in opera
# [15:09] <zcorpan_> (except the declarative that is)
# [15:13] <anne> all, dunno, interesting
# [15:15] <zcorpan_> http://simon.html5.org/test/css/magic-body/magic-body.rar
# [15:15] <zcorpan_> (README.txt contains a table which lists which tests opera fails)
# [15:15] <zcorpan_> HTH
# [15:16] <anne> hehe
# [15:38] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [15:56] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [16:12] * Quits: zcorpan_ (zcorpan@84.216.42.62) (Ping timeout)
# [16:17] * Joins: h3h (bfults@66.162.32.234)
# [16:24] * Quits: htmlr (htmlr@203.217.80.229) (Quit: htmlr)
# [16:39] * Joins: hasather (hasather@81.235.209.174)
# [16:40] * Joins: billmason (billmason@69.30.57.156)
# [16:47] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: さようなら)
# [17:04] * Parts: anne (annevk@213.236.208.22)
# [17:06] * Joins: anne (annevk@213.236.208.22)
# [17:08] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [17:08] * gsnedders tries to make sense of what Gareth is saying
# [17:09] <gsnedders> we have a fatal parsing error, then we start parsing again to process the document as HTML 4.01…
# [17:09] <gsnedders> why have a fatal parsing error in the first place?
# [17:10] <Lachy> he doesn't understand that reparsing is a major performance hit, can have security issues, and...
# [17:10] <anne> browsers implementing that will have a disadvantage opposed to browsers that don't
# [17:10] <anne> so it won't happen
# [17:10] <anne> this was already pointed out several times on the mailing list
# [17:11] <anne> probably not worth repeating once again
# [17:11] <Lachy> he's living in Utopia, where all authors of HTML5 will ensure that their pages work before publishing
# [17:12] <anne> i don't think he is
# [17:12] <Lachy> he also fails to comprehend the possibility of an unencoded ampersand sneaking it, or something equally trivial, which would inexplicably break everything
# [17:12] * anne would like to be there though
# [17:12] <Lachy> I was going to ask him what it's like living there, but I don't think I'll be sending the mail
# [17:13] <gsnedders> the number of times I've committed code (not markup) into public repositories that causes parse errors helps make that point
# [17:13] <gsnedders> with more minor changes, you may not check that it works before pushing it
# [17:14] <Lachy> has anyone heard of Gareth before? Know what his background is and how much experience he has with web dev?
# [17:15] <anne> Doesn't matter
# [17:15] <gsnedders> None with actually parsing HTML, for certain
# [17:15] <Lachy> I know it doesn't matter, I was just wondering
# [17:18] * gsnedders gives up on the majority of long running threads
# [17:21] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [17:26] * Joins: gavin_ (gavin@74.103.208.221)
# [18:12] * Joins: zcorpan_ (zcorpan@84.216.42.62)
# [18:16] * Quits: zdenko (zdenko@193.77.152.244) (Quit: zdenko)
# [18:16] * Joins: MrNaz` (Naz@203.214.95.166)
# [18:17] * Quits: MrNaz (Naz@203.214.95.166) (Ping timeout)
# [18:25] * Joins: MrNaz (Naz@203.214.95.166)
# [18:25] * Quits: MrNaz` (Naz@203.214.95.166) (Ping timeout)
# [18:26] <gsnedders> heh. Jeff's brought up a brilliant point: "If someone makes a grammatical error when speaking to you, do you tell them that there was an error and reject everything they say until they correct it?"
# [18:27] <Philip`> That depends on whether it was a minor error which you can recover from, or whether they were saying complete gibberish in which case you'd reject what you heard and ask them repeat it more clearly
# [18:29] <gsnedders> it was in the context of a minor mistake
# [18:29] <beowulf> the point is that languages shouldn't be draconian in handling errors, they should try, try and try again to convey meaning
# [18:29] <hsivonen> gsnedders: can we reject everything said by people who make vocabulary errors? (depreciated... :-)
# [18:30] <gsnedders> hsivonen: a splling mistke?
# [18:30] <Philip`> beowulf: But human languages have some limit beyond which they don't try to handle errors any more
# [18:30] <beowulf> maybe we need dialects
# [18:30] <gsnedders> hsivonen: I take it I said depreciated from that comment, though ;)
# [18:30] <beowulf> Philip`: at that stage we try a new language, not give up
# [18:31] <Philip`> But that would be like reparsing, which browsers won't do :-)
# [18:31] <hsivonen> gsnedders: no, I meant in general
# [18:32] <gsnedders> hsivonen: ah
# [18:32] <Philip`> Anyway, I think that just means the analogy shouldn't be taken in that direction since it breaks down
# [18:33] <beowulf> Philip`: i'm simply of the opinion that the kind of error handling in xhtml is unacceptable, you can't not try and communicate
# [18:33] <beowulf> oh, that was bad
# [18:33] <beowulf> "can't not" # very bad
# [18:33] <gsnedders> "First letter of sentenced not capitalised. Unable to process sentence."
# [18:34] <beowulf> (I also have opinions now, having read 100's of emails, go me)
# [18:34] <Philip`> Depreciating elements is quite a negative thing to do - I think the spec should instead mark all the nice elements as appreciated, and the conformance checker could give you a little gold tick each time you use one, then everybody would love writing HTML
# [18:34] * gsnedders attempts not to burst out laughing
# [18:36] * Quits: myakura (myakura@125.194.247.196) (Quit: Leaving...)
# [18:38] <hsivonen> "Gareth Hay asked recently
# [18:38] <hsivonen> "Are you suggesting that HTML should allow tags to be written in
# [18:38] <hsivonen> any language ?", and I most certainly am. "
# [18:38] <hsivonen> I guess I'll give up now
# [18:39] <beowulf> is this your last post on irc?
# [18:40] <hsivonen> no. my last reply to philip taylor (webmaster) in that subthread
# [18:44] <Lachy> I should have guessed the role attribute would come up eventually :-(
# [18:44] <Lachy> (see John Foliot's latest post)
# [18:47] * Joins: edas (edaspet@88.191.34.123)
# [18:53] <zcorpan_> oops, seems like i responded to something that had a massive tree under it which i haven't read
# [18:53] <zcorpan_> so much for opera's tree view :|
# [18:53] <Lachy> zcorpan_, never mind, I've responded to heaps without reading whole thread. I've still got 212 on public-html to read
# [18:54] * Lachy only got through ~150 mails today
# [18:55] <zcorpan_> yeah, though i'd like to know if there are replies already before i reply... opera is so clever that it collapses the tree so i don't get to see it
# [18:56] <zcorpan_> great feature!
# [18:57] <zcorpan_> (the indicator that it is collapsed is cropped because the subject line is too long)
# [18:58] <Lachy> doesn't it have a +/- expander button next to it?
# [18:59] <Lachy> what other indicator would there be?
# [18:59] <zcorpan_> oh, right there is
# [18:59] <zcorpan_> it would say how many messages there are after the subject
# [19:00] <Lachy> oh, nice
# [19:00] <zcorpan_> could be but i don't get to see it very often... usually the subject line is too long
# [19:03] <Lachy> hsivonen, I mostly like your proposal for the style attribute, but I'm not so sure it's a good idea to retain the WYSIWYG sig, and <font> should definately be made non-conforming
# [19:03] <zcorpan_> Lachy: agreed
# [19:23] * Quits: ROBOd (robod@86.34.246.154) (Ping timeout)
# [19:26] * Joins: ROBOd (robod@86.34.246.154)
# [19:27] * Quits: zcorpan_ (zcorpan@84.216.42.62) (Ping timeout)
# [19:28] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [19:33] * Joins: gavin_ (gavin@74.103.208.221)
# [19:52] * Joins: zdenko (zdenko@84.255.203.169)
# [19:52] <xover> Anyone know if the Patent Policy implications of the WHAT WG submission has been dealt with?
# [19:53] * Joins: Zeros (Zeros-Elip@204.97.106.48)
# [19:54] * xover checks userlist...
# [19:55] * xover pings anne and Hixie...
# [19:56] <hsivonen> xover: which implications specifically?
# [19:56] <xover> The proposal only mentions copyright assignment; has it been vetted for Royalty-Free Patent Licensing as well?
# [19:57] <hsivonen> xover: as in patent searches?
# [19:58] <xover> No, as in with normal submissions from companies to the W3C. The WHAT WG submission is a little out of the ordinary for this.
# [20:00] <hsivonen> pardon my ignorance. how are normal submissions vetted?
# [20:01] <xover> IOW, do the undersigned on the proposal claim they either are not aware of any patents covering the material, or any patents are available for license on a Royalty-Free basis.
# [20:02] * Quits: Zeros (Zeros-Elip@204.97.106.48) (Quit: Leaving)
# [20:03] <h3h> from what I gather that doesn't matter
# [20:03] <h3h> when the spec goes to call for comments any vendors must explicitly object to any content that is under their patent control
# [20:03] <h3h> and if they don't, it's free for use in the final spec
# [20:04] <h3h> Apple has already said they won't do that for <canvas> etc.
# [20:04] <h3h> (the above was gleaned from several list posts)
# [20:04] <xover> Hmm. Ok. So we assume it won't be a problem, but it hasn't been explicitly dealt with?
# [20:05] <h3h> it was explicitly addressed on the list. check the earliest archives...probably in the first 50 threads
# [20:05] * xover can barely keep up with the latest threads... :-)
# [20:06] * h3h has just been marking all unread threads as read for the past week
# [20:06] <h3h> it's just more of the same
# [20:07] <xover> Yeah, too much noise to pick out the productive bits.
# [20:07] <h3h> I just drop in on Maciej's or Ian's replies every now and then to see what's going on :)
# [20:07] * xover looks accusingly in the Chairs' general direction...
# [20:09] * xover checks clock to find out how long he has to decide whether to object or not...
# [20:15] <hsivonen> xover: surely you aren't going to object on patent grounds?
# [20:15] <xover> No, no. :-)
# [20:16] <xover> If it was an actual problem I would, but mainly just to make sure it got handled.
# [20:16] <xover> I'm reviewing the questions up for vote against the Charter, among other things.
# [20:18] <xover> Trying to figure out which of my misgivings are for substantive reasons and which are just preference, subjective, etc.
# [20:19] * h3h bahs at John Boyer's reasoning for a "no"
# [20:20] <h3h> it's a semantically invalid argument if we're going to be picky
# [20:21] <schepers> xover, what issues are you concerned with?
# [20:22] <xover> Trying to figure that out, actually. :-)
# [20:22] <xover> I think at the base I'm concerned with the attitude and goals underlying, in particular, the “HTML5” submission.
# [20:22] <schepers> I can totally understand that
# [20:23] <xover> But I'm as yet undecided on whether or not there is anything in there that constitutes a substantive issue.
# [20:23] <schepers> I think they have made a very poor attempt at explaining why this would be a good idea
# [20:23] <schepers> the arguments have been, in tone if not in substance, "shut up and let us have what we want"
# [20:24] <xover> Particularly since the Charter, on further review, seems to one of the things I'm concerned about (and the Charter is out of scope for the current vote).
# [20:24] <h3h> I think good explanations have been made, but have been drowned out in confusion and misunderstandings
# [20:24] <schepers> h3h: I agree, there have been very lucid posts
# [20:24] <xover> Another concern for me is the navel-gazing quality of the arguments.
# [20:25] <schepers> xover: that's been on both sides
# [20:25] <xover> yes
# [20:25] * hsivonen notes that the attitude and goals have translated to results: http://ln.hixie.ch/?start=1172653243&count=1
# [20:25] <gavin> schepers: which "this" are you referring to above? the current vote for editor/starting point/name?
# [20:26] <schepers> gavin: yes, specifically taking the WHAWG proposal
# [20:27] <xover> hsivonen: Yes, I'm the first to lambast the recent hostory of W3C WG's, the late HTML WG in particular, particularly on secrecy and non-responsiveness.
# [20:27] <h3h> have you read the reasons given in the survey next to the "yes" answers?
# [20:27] <schepers> I think it's reasonable to expect people to read it before judging, but I also think that it's unreasonable to demand an immediate vote on it without giving people a chance to read it
# [20:27] <xover> hsivonen: However, that was not the issue I was referring to.
# [20:28] <h3h> schepers: to be fair, it's asking whether or not the spec should be admitted for discussion -- reading it is not a prerequisite
# [20:28] <h3h> knowing the gist is, however
# [20:28] <schepers> h3h: I don't think that's realistic... in a way, it is a fiat, because of momentum
# [20:29] <h3h> I don't see it as fiat at all. the resulting discussions in this WG could invalidate everything in the current spec
# [20:29] <hsivonen> xover: it illustrates getting stuff done vs. discussing it in a committee
# [20:29] <h3h> fiat would be mandating its inclusion in the final spec somehow
# [20:30] <xover> hsivonen: Sure. But the WHAT WG does not represent the needs of the sum total of the web.
# [20:30] <schepers> h3h: but it also includes buying into Hixie as the editor, and he's very tenacious, and would strongly resist any attempts at changing it, right?
# [20:30] <h3h> the WHAT WG represented and championed the needs of web authors and browser vendors (two of the largest groups on the web) for several years
# [20:31] <h3h> schepers: that's a completely separate question
# [20:31] <xover> hsivonen: And that realization has not been particularly prominent in their interactions with those who dissent.
# [20:31] <h3h> and Hixie doesn't resist changes to the spec when they're presented with a strong argument and real evidence
# [20:31] <gavin> schepers: I don't think it's fair to say that Hixie would resist any attempt to change the spec
# [20:31] <h3h> he's one of the most rational people I've had the pleasure of interacting with on specs
# [20:32] <gavin> schepers: he has been convinced to change things, and has said there are things he'd like to change
# [20:32] <schepers> xover: fwiw, I have decided that on most of the substantive issues, it's most productive to go with the flow on this vote
# [20:32] <xover> I would have formally objected to Hixie as Editor if the Charter hadn't explicitly said that the HTML WG should “actively seek convergence with the WHAT WG”.
# [20:33] <xover> schepers: I'm, as mentioned, as yet undecided on whether any of my misgivings represent actual substantive issues.
# [20:34] <schepers> fair enough
# [20:34] <Philip`> I believe any reading of the spec requires discussion beforehand - there are several obvious areas (like <font style>, WF2 repetition) where the spec says something that most WHATWG people are unhappy with and which are very likely to be changed, but you can't tell that just from reading it; so the reading and arguments against features need to be guided carefully so that they're usefully targetted
# [20:35] <Philip`> Uh, I've forgotten why I thought that was a relevant point, except I guess that means reviewing the spec before judging it will take quite a bit of time and cooperation
# [20:36] <schepers> xover: let your conscience decide, but also consider what the implications of a formal objection are, and if that meets your goals
# [20:37] <Philip`> Oh, maybe the point was that that reading would require significant commitment too, hence the value of formally voting before starting to do that work
# [20:40] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [20:41] * Joins: dbaron (dbaron@63.245.220.242)
# [20:47] <xover> Ugh. Anyone else occasionally getting the raw markup instead of cooked display for the ballot page in Safari?
# [20:54] * Joins: olivier (ot@128.30.52.30)
# [21:21] * Quits: mw22 (chatzilla@84.41.169.151) (Ping timeout)
# [21:27] <gsnedders> xover: yes
# [21:27] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [21:28] <xover> I should break out a packet sniffer and see wtf is going on there.
# [21:46] * Quits: billmason (billmason@69.30.57.156) (Quit: .)
# [21:56] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [22:01] * Joins: gavin_ (gavin@74.103.208.221)
# [22:03] <mjs> 77 new emails since I went to bed last night (which was at 4 AM!)
# [22:04] <xover> Enjoy the firehose. Hope you were thirsty. :-)
# [22:05] <Zeros> I have 591 unread at this point
# [22:06] * xover checks the clock again...
# [22:07] * xover wishes ballots would be announced on a Friday and close on the Monday after the weekend next...
# [22:11] <gavin> I have 0 unread messages, but some of them haven't been read
# [22:11] <gavin> depends who they were from and what the subject was
# [22:12] <mjs> I've been sending enough email that I have to read through it to see what might be a reply to me, directly or indirectly
# [22:12] <Zeros> I need to figure out how to get Mail.app to group by subject :/
# [22:12] <Zeros> It's really hard to follow this when there's 380 emails and they go from topic to topic
# [22:12] <gavin> well, yeah, I don't delete them indiscriminately
# [22:13] <Zeros> The support existing content thread has the <font> thread all mixed in with it
# [22:13] <Zeros> heh
# [22:13] <Zeros> I guess I could just start reading them on gmail itself
# [22:26] <h3h> hooray Gmail
# [22:32] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:45] <gsnedders> Zeros: view -> organise by thread
# [22:45] <Zeros> gsnedders, oh they are organized by thread like that
# [22:45] <Zeros> But it doesn't group by subject line
# [22:45] <gsnedders> ah.
# [22:45] <Zeros> I don't know why
# [22:46] <gsnedders> someone who actually knows the subtle difference
# [22:47] <Zeros> :)
# [22:47] <Zeros> I guess it's grouping on the reference headers?
# [22:47] <Zeros> not sure, but what ever it's using it's a real pain
# [22:47] <Philip`> Wow, radial gradients are 'fun'
# [22:48] * mjs is not surprised that validity fetishists are also grammar nazis
# [22:49] <Zeros> gsnedders, http://enfinitystudios.thaposse.net/personal/mailapp.png see what I mean?
# [22:49] <Zeros> that "thread" is 300 emails long, and it goes in and out of different subjects
# [22:49] <gsnedders> Zeros: I know what you mean
# [22:49] <gsnedders> Zeros: I use Mail.app myself
# [22:50] <Zeros> Is it doing that for you too?
# [22:50] <Zeros> mjs said his wasn't, so I'm curious what the difference is
# [22:51] <xover> mjs: You took me to task for such characterizations just the other day...
# [22:51] <mjs> xover: I don't mean it to be perjorative, entirely, though I somewhat disagree with such sentiments
# [22:52] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [22:53] <xover> `twas a friendly reminder is all... :-)
# [22:54] <xover> «You need two things on Usenet — a civil tongue and a thick skin.» - Steve Dorner
# [22:55] <xover> I am as mercifully equipped with the latter, as I am sadly lacking of the former. :-|
# [22:58] * Joins: Roger (roger@213.64.74.230)
# [22:59] <xover> schepers: ping?
# [23:00] * Joins: hyatt (hyatt@24.6.91.161)
# [23:10] * Joins: jdandrea (jdandrea@68.192.161.254)
# [23:12] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
# [23:12] <schepers> xover: pong
# [23:13] * beowulf wonders how printers have done so well without <em class="pleading">
# [23:13] * Joins: hyatt (hyatt@24.6.91.161)
# [23:13] <xover> Ah, mind if I take it to privmsg?
# [23:13] <schepers> feel free
# [23:13] <schepers> mjs: I thought you were being sarcastic about the linguistic prescriptivist/descriptivist comment on IRC, but I see know you were serious :)
# [23:14] * Joins: John_Boyer (boyerj@32.97.110.142)
# [23:14] <John_Boyer> rrsagent, make minutes
# [23:14] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/04-html-wg-minutes.html John_Boyer
# [23:14] <John_Boyer> rrsagent, make log public
# [23:14] <RRSAgent> I have made the request, John_Boyer
# [23:14] * Parts: John_Boyer (boyerj@32.97.110.142)
# [23:18] <mjs> schepers: I think it's an instructive analogy to our situation
# [23:19] <schepers> I agree
# [23:19] * Joins: John_Boyer (boyerj@32.97.110.142)
# [23:19] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [23:19] <schepers> (I thought you were poking fun at me earlier, since I used "prescriptionist" (misspelled, though) in an earlier email)
# [23:20] <John_Boyer> hyatt, no you weren't that mean
# [23:20] <John_Boyer> anne, <foo:bar/> doesn't parse in namespace aware XML processors
# [23:20] * h3h finds it amusing/disturbing that rrsagent doesn't log actions along with messages
# [23:20] <John_Boyer> and by all means, mjs, stay the course
# [23:20] <John_Boyer> bye for now :-)
# [23:20] * Parts: John_Boyer (boyerj@32.97.110.142)
# [23:20] <schepers> I studying linguistics myself, and that has actually changed my view on a lot of things
# [23:32] * Quits: tH (r@87.102.32.222) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [23:41] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [23:54] * Dashiva grumbles at rampant doubleposting to www/public
# [23:59] * Parts: hasather (hasather@81.235.209.174)
# [23:59] * Joins: zdenko_ (zdenko@84.255.203.169)
# Session Close: Sat May 05 00:00:00 2007

The end :)