<Zeros> What's the purpose of the value attribute on li?

<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?

<Zeros> oh

<Hixie> start gives the value of the first item

<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

<Zeros> The description of what value does under <ol> is much more clear

<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."

<Hixie> oops

<Hixie> can you said me a mail about that?

<Hixie> i'll fix it when i next work on lists

<Zeros> sure

<Hixie> ian@hixie.ch or if you're on the whatwg list whatwg@whatwg.org

<Hixie> thanks

<Zeros> np

maybe i am conflating xul templates with this feature i dunno

but if i am going to auto-generate some giant tree view or table or list or menu

i want to be able to bind a template to a back-end model DOM

<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.

which part?

<Hixie> whole thing

it's not clear to me that this particular feature has to degrade gracefully

<Hixie> the wf2 repetition model actually works in legacy browsers (with some server side support)

really?

<Hixie> yeah

<Hixie> http://www.whatwg.org/demos/repeat-01/

<Hixie> try it in safari

hmmm what makes yo usay that my proposal wouldn't degrade gracefully the same way?

legacy browsers would fail to bind to the model

and would render the template

the buttons could still be hacked ...

so seems like i'm not proposing anything that couldn't still work in legacy UAs

<Hixie> well i'm certainly open to that kind of thing

anyway i think this feature transcends forms the way i'm proposing it

<Hixie> i just haven't been able to come up with a design myself

<Hixie> i agree that it's not a form thing

<Hixie> and i'd love to drop the repetition model

<Hixie> in favour of something better

cool

this kind of ties in with datagrid too

since it has the concept of binding to a back end right

<Hixie> yeah

<Hixie> <datagrid> binds to a JS-provided or markup-backed tree structure.

maybe i can draft something in my copious spare time

hahah

<Hixie> heh

<Hixie> we need to have lunch with a whiteboard one of these days

<Hixie> and hash something out

yeah

<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.

<Zeros> unknown*

to me repetition model is one of those major shifts that may not be backwards compatible

it's not like datagrid will degrade right

<Hixie> Zeros: yeah, it only works in legacy html4-compliant UAs, sadly. one more reason i'm not a big fan of it.

i think we should strive for degradability as much as possible

but not 100%

<Hixie> hyatt: well, if the data backing your datagrid is a markup <table>, then yes, it will (it'll degrade to a table)

if the feature is compelling enough

<Hixie> hyatt: but if the data backing your datagrid is a JS component, then you'll need more JS to make it degrade.

Hixie: ah, is the model forced to be inside the datagrid or something?

<Zeros> I agree with hyatt, but I think there needs to be a better way than the repetition model.

<Zeros> repeat-action="delete" would have been a better solution since it would allow <input type="submit"

<Zeros> Then we get IE support

<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

<Hixie> hyatt: one of the rules is basically a <table>

<Hixie> Zeros: hyatt and i are in agreement here

<Zeros> :)

<Zeros> Hixie, So are you going to reconsider it?

<Hixie> hyatt: so looking at the definition, the <datagrid> can be backed by a <table>, a <select>, a list (<ol>, <ul>)

<Hixie> hyatt: and it'll generate the right data grid out of it (with the right context menus, etc)

<Hixie> Zeros: everything in the whole spec is always up for reconsideration, especially when someone points out a better solution as hyatt is doing

<Zeros> alright

Hixie: i think this points to a way to degrade as well

imagine something like <datagrid>

but that is independent of a particular widget

e.g., <repeat> that does what datagrid does

and that can bind to these degradable models

<Hixie> hyatt: yeah... yeah! this could work

<Hixie> i wonder how we can do nested repeats

models nest in certain forms (like lists)

but yeah

<Zeros> Can't you just spawn a new repeat context?

ok gotta head home

will be on later

<Zeros> Hixie, Maybe reconsider the way to substitute in values in attributes as well

<Hixie> if we go down the road hyatt suggested, the whole thing would be redone entirely

<Zeros> okay

<Zeros> Oh, and someone already mailed the whatwg list about the li attribute

<Hixie> cool

<Hixie> hyatt: to answer the question you just mailed to public-html, the repetition model integrates with the form submission stuff

<Hixie> that's why it's in wf2 and not wa1

<Hixie> however, note that there is a section for it in the wa1 spec already, i just haven't moved the stuff over

<Hixie> (since we might just drop it)

<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 one has to get/set values on radio buttons, for example

Hixie: ah ok
... i have honestly only skimmed the repetition model section

which was one reason i was being quiet during all the forms debating

:)

<mjs> hello all

hey mjs

<mjs> hello hyatt

<mjs> hyatt: so was I really that mean to John_Boyer?

you have not been mean

i think now that technical specifics have actually been mentioned, that this discussion got much better

<mjs> I didn't think so, but I try to double-check in such cases

there's been too much hand-wringing without meaty technical details

thats why i enjoyed finally seeing a real criticism (e.g., the repetition model)

thats how progress will get made

<Hixie> schepers: some, not for radio buttons as i recall, though.

<schepers> that's something I'd really like to see, though I haven't thought of how to degrade it in older browsers

<mjs> hyatt: I thought even the list of requirements was really helpful

yeah

<mjs> before I very literally did not know what the XForms contingent wanted

<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

<schepers> I think that would make Raggett's top 10

<schepers> but I'm guessing

<mjs> yeah, I assumed his view was in step w/ the rest of the Forms WG

<schepers> no idea, I just know he really likes declarative solutions

<zcorpan_> hyatt, mjs: have you seen http://bugs.webkit.org/show_bug.cgi?id=13568 ?

<mjs> zcorpan_: now I have

zcorpan_: yes i've seen it
... not going to move on it though until a decision has been reached

but at this time i don't think we should change it

<zcorpan_> hyatt: the csswg said they won't change the spec unless implementors do this

<zcorpan_> hyatt: currently there isn't interop

i believe we are pretty close to ffx

in our behavior

<mjs> hyatt: per the firefox bug, we seem to be the only ones following the spec

<mjs> er

<zcorpan_> hyatt: for background, yes. for overflow, no

<mjs> per the mozilla bug

mjs: yeah thats because i read the spec when i implemented this

i read the spec when doing overflow :)

<mjs> Mozilla and Opera both fail to match in one way or another

anyway i'd need more technical details

before proceeding

since even with <body> quirks vs.. strict has it doing very different things in html

<mjs> of course, CSS WG also wants to make table layout different between HTML and XHTML, which would make this difference trivial by comparison

for example <body> fills the viewport in quirks mode

but it doesn't do that in strict mode

which makes applying the overflow of the <body> to the viewport kind of crazy

we even still do that in html strict mode

which is bizarre

<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)?

<mjs> are background-color and background-image supposed to be different between HTML strict mode and XHTML?

i think the whole thing is screwed up right now

i think body should be mandated to fill the viewport

and then yes i would be fine with consistency

<zcorpan_> mjs: per the current spec, yes

<mjs> zcorpan_: what's the difference?

<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

i believe we do propagate the background up even in xml

don't we?

<zcorpan_> hyatt: root->canvas, yes

<mjs> so in strict you propagate the background up, but the body doesn't fill the viewport?

<zcorpan_> mjs: exactly

no i don't think that's it

body doesn't fill the viewport even in html strict mode

<mjs> I wish there was just some CSS property that said "this element fills the viewport if otherwise it would be smaller

mjs: this is all stupid

<mjs> then we could say it applies to the body and there'd be no special case

mjs: everything should just be fixed to be like quirks mode

<zcorpan_> i still have speccing quirks mode on my todo list

mjs: the real error here is in making <html> and <head> able to have any rendering at all

it's silly

<body> should just function as the root

and fill the viewport

that's effectively the sensible behavior

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

it's one of the main reasons people stay in quirks mode

the whole situation is a gigantic mess

instead we get crazy behavior like a tiny body element being allowed to set overflow on the whole viewport

<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

<mjs> then you don't need an HTML-specific special case

you shouldn't have to though

<mjs> and the desire to be different from XHTML goes away

<zcorpan_> hyatt: i don't disagree, but i think going back to quirks mode behavior for this now would break some pages

i doubt it, since WinIE's body always fills the viewport

even in strict mode

unless you mean xml pages

in which case the 8 people authoring xml on the web can update their pages

;)

<zcorpan_> hyatt: no it doesn't, you can apply a border to body in ie and it won't be around the entire viewport

<zcorpan_> in html strict

ah

ok didn't know they did that in strict mode

is that new in ie7

or does ie6 work that way

<zcorpan_> no, ie6

ah ok then i guess we can't change it

<zcorpan_> indeed

<zcorpan_> but we can make xhtml be the same as html strict

sure, would need to know the differences though

i know overflow is one

i thought our background code was identical though

i don't recall having an htmldocument check in that code

<zcorpan_> identical to what?

to html strict

xml and html strict should be the same

for background propagation

in ToT WebKit

<zcorpan_> not according to the results i got (though i didn't test myself, the results could be wrong)

<zcorpan_> i think the test cases should cover all cases

<zcorpan_> you just need to implement what the spec says you should do for html, but also for xhtml

and i'm saying that aside from overflow i think we already do

but i could double check

<zcorpan_> ok

<zcorpan_> (if so, then you'd be more like opera than gecko)

ah nvm

i see an ishtmldocument check.

it's actually not even intentional

it was just to call document()->body()

hah

<zcorpan_> :)

but document.body is now defined on XML docs

since it had to be because the dom test suite relied on it

so that cast isn't needed now

<zcorpan_> ah, my tests rely on document.body too

ah nvm there's another isHTMLDocument check

yeah i guess i did this on purpose

probably read a spec or something!

:)

<zcorpan_> probably :)

it's an easy patch

just 3 places where isHTMLDocument() is used as a guard

<Zeros> What's TOT stand for?

oh sorry, "Tip of Tree"

our current code

<Zeros> yeah, just wasn't sure what the letter really meant

zcorpan_: are you simon pieters?

ah i see that you are

you people and your "Z" names. confusing me!

<zcorpan_> hyatt: yes :)

i'm a little bit nervous changing to not match ffx

since of course people will just blame us

they always do

:)

<zcorpan_> hyatt: you chould change overflow

since ffx = standards mode

<zcorpan_> hyatt: gecko passes all overflow tests

<Zeros> hyatt, nothing wrong with not matching ffx you just need to convince the gecko developers to match you

so basically we match the current spec the most closely right now

<zcorpan_> hyatt: yes

that'll teach me to trust specs

<zcorpan_> hyatt: but you still have bugs in some edge cases

probably background-position and repeat and stuff

we don't do any of that right

in the case where the body is smaller than the viewport

<zcorpan_> yeah, that's one

<Zeros> At least the background-repeat when the element was too small bug is fixed! :)

but we support multiple backgrounds so that makes up for it

<zcorpan_> :)

<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

<zcorpan_> and even if they do they probably style the root element, so it wouldn't affect them

<mjs> zcorpan_: in current nightlies, we send application/xhtml+xml in our Accept header

<zcorpan_> mjs: ok

<mjs> but that does make it unlikely that anyone was depending on our old XHTML rules

<zcorpan_> indeed

<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

<mjs> I think nightlies have the entity stuff fixed

we fixed most entity problems

safari 2 has broken entities

but ToT does not

<zcorpan_> do you parse the internal subset?

Safari 2 = 2 years old

WebKit = very different

<zcorpan_> (safari 2 doesn't parse the internal subset in xml iirc, or at least entities declared in it don't work)

<Zeros> hyatt, yeah, the nightlies are much better

<Zeros> Any chance we can get a way to turn off CSS?

<Zeros> There's a way to disable JS, Plugins, Java and everything but

<mjs> I'm not sure if we support the internal subset

yeah problem is there's no security argument for turning off css

<mjs> but we did fix other common entity issues

turning off css is really a web developer sort of feature

<Zeros> hyatt, Stick it in the debug menu then?

could maybe put it in the debug menu

or teach our web inspector how to do it

<mjs> Zeros: you can turn off CSS by putting a value of "initial !important" for every CSS property in your user stylesheet

mjs: not true

style="..."

and all of the mapped attributes

<mjs> hyatt: style="" would override !important rules?

<zcorpan_> they shouldn't...

<mjs> (I don't think so)

<Zeros> I'd love if the web inspector had inputs to mutate the DOM

<mjs> I don't know about mapped attributes, I assume not in that case either

yeah mapped attributes would lose to a user important rule

yeah i guess that would work

<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

correct

actually no

<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

mjs: i am not sure disable CSS means "turn off the UA sheet"

<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.

mjs: i think it means turn off author and user

<Zeros> is a*

mjs: so actually i don't think you can do it from the user sheet

disable CSS really means "turn off all author CSS"

<Zeros> yeah

<Zeros> hyatt, might be nice if it had more so you could select between minimal and high contrast or whatever sheets you wanted

<mjs> yeah, no simple way to do that

it's very simple to do that with a code patch

but yeah no way to do it with safari 2 i think from the user sheet

<Zeros> There's also #5 of the CSS conformance rules that Safari doesn't follow

<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."

<Zeros> Which is where Firefox and Opera expose the No CSS option as well.

<Zeros> Is there a problem with adding that to the View menu in the same manner?

<mjs> Zeros: it's inappropriate for the spec to demand fiddly expert-level UI features

<mjs> (it is possible to select from alternate stylesheets via javascript: URLs or under control of script in the page though)

<Zeros> that doesn't work if you have JS disabled on the page

<Zeros> mjs, from the same argument you could say Safari doesn't need font +/- options since JS can do that too

Zeros: a bookmarklet is considered conformant btw

<Zeros> Both Opera and Firefox expose the alternate stylehsheet options though

<mjs> Zeros: we have those because of perceived need for typical end-users

Zeros: this came up with Mac IE and tasman
... and a bookmarklet in the bookmarks bar was ruled as being conformant

<Zeros> hyatt, really? interesting

<mjs> we lack a lot of prefs that other browsers have in the UI

Zeros: my main reasoning behind not exposing alternate stylesheet UI
... is that it needs to be implemented well before exposing it

and implementing it well is hard

<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

a crappy "you have to click this for every page in the domain" rule is no good

not remembering choices is no good

<Zeros> hyatt, Okay, that's a good argument. Better done right than poorly for the sake of adding it

right

and doing it right is pretty hard

<zcorpan_> i think konq remembers the choise

it's also tricky to do it in such a way that doesn't conflict with the site's own fiddly cookie-setting stuff

<Zeros> plist with the domain I guess

<mjs> and of marginal value for most people

it's funny too because browsers tend to be so buggy at changing stylesheets dynamically

that people just use the server to do the switching often anyway

<Zeros> Well, I'd settle for a disable user stylesheets option in the debug menu at this point.

user?

<Zeros> err author

you mean author?

heh

<Zeros> yes

we have a big desire to beef up our development tools

and turning off css fits naturally into that

<Zeros> hyatt, Have you ever looked at Shiira?

Zeros: haven't looked at 2.0 yet

did look at < 2.0

<Zeros> The interface is nicely done.

it's very unpolished though

some good ideas though

<Zeros> yeah

has the feel of being like 80% finished

<Zeros> Sunrise also has a very cool feature that lets you edit code right in the source view and see changes

yeah i love that

big fan of that

<Zeros> me too

<zcorpan_> opera has that too

<Zeros> hmm, the user agent list doesn't let you go back to automatically chosen

yay i compiled

boo i didn't link

<Zeros> heh, Shiira has the Exposé tabs that karl was asking for

<anne> lots of e-mails...

<anne> "*snork* Come on, man, not while I'm eating lunch." heh

<mjs> anne: I didn't think it was that funny, but I'm glad Chris has a sense of humor about it. :-)

<anne> As long as XHTML is draconian I don't really care about it

<anne> Fortunately the holy mobile world is helping us out there :)

<mjs> it has value in providing a draconian path for those who want one

<mjs> though apparently some will be unsatisfied until all available options are draconian

<anne> It's just for the syntax. I don't see much value in just doing it for the syntax.

<mjs> that is true, surface-level syntactic checking is some of the less interesting automated checking you could do

<anne> Maybe if it was like Silverlight it would work. But you can no longer introduce such a thing on top of XML

<anne> And it would hurt extensibility etc. a lot.

<mjs> anne: I think the most entertaining thread is John Boyer's with me

<anne> Yeah, your charter citations were nice

<mjs> well, mainly it was his parts that I found entertaining

<anne> oh right

<anne> yeah, XML5 would too

<mjs> zcorpan_: the error handling in the HTML5 serialization isn't required for conformance?

<zcorpan_> mjs: you must either do as described or abort when you don't want to do as described

<mjs> interesting

<zcorpan_> mjs: strictly speaking you may also do whatever you want for pages that don't start with the new doctype

<schepers> that is odd

<schepers> I noticed that as well

<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."

<anne> The thing is that we do the latter we won't be used.

<mjs> I wonder why it's written that way

<anne> Where for a conformance checker it might be reasonable (thought not desirable)

<anne> if we do the latter*

<zcorpan_> 8.2.4.1. The initial phase...: (not starting with correct doctype) "This specification does not define how to handle this case. "

<mjs> I could almost consider either following the rules or aborting on *any* error to be reasonable

<mjs> but this effectively makes a large set of possible error handling algorithms

<anne> mjs, the current conformance checker recovers from some errors

<anne> mjs, but not all

<xover> I wonder where this desire for draconian error handling comes from...

<anne> I don't know

<anne> Forbidding it doesn't make much sense to me though

<anne> mjs, it should probably be a requirement for user agents to always recover

<anne> mjs, well, at least for the class "web browsers" are in

<mjs> anne: well, a conformance checker seems like a pretty different case from browsers or data mining tools

<zcorpan_> xover: so you can browse well-formed pages with your mobile that can't afford to recover from parse errors... ;)

<anne> yeah, didn't you hear, the mobile web only does XHTML

<anne> and it works great

<anne> XML everywhere!

<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

<anne> but if it can recover that's ok as well, so it can point out more errors

<mjs> for tools that intend to process the data in a more meaningful way, it's unclear if that freedom has benefits

<mjs> right

<anne> yeah, I think I agree with you

<xover> For a conformance checker, bailing out at the forst error is certainly the least usefull option.

<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

<zcorpan_> but they could still recover from other errors

<anne> good point

<anne> adoption agency sucks rocks

<mjs> I guess the algorithm guarantees you will either get the same success result as any other conforming implementation or abort

<schepers> you trying to adopt a kid, anne?

<anne> unfortunately it can't be changed in a way that would not require "weird things"

<anne> while remaining compatible

<mjs> adoption agency is the least weird way of addressing the compat issues I think

<zcorpan_> xml5 could do without it i presume? :)

<anne> yeah, xml5 has super simple error handling

<anne> explained it on #whatwg yesterday

<zcorpan_> oh, must have missed it

<anne> it's not actually in a spec yet or so, #whatwg is the only documentation i've got (besides my head)

<anne> mjs, I agree, but CSS5 is too big a research project for a semester

<mjs> fair enough

<zcorpan_> anne: how do you handle bogus namespace prefixes and bogus namespace declarations?

<anne> heh, the arguments from John Boyer are exactly what I would say about his position...

<anne> zcorpan_, what about them?

<zcorpan_> how is this document parsed? <foo:bar/>

<zcorpan_> is it element foo in namespace "" with namespace prefix bar?

<anne> I was thinking of {"", "foo:bar"}

<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

<zcorpan_> ok. what about <foo xmlns:xmlns="bar"/> ?

<mjs> Hixie: yeah, the only part I'm unsure of is being allowed to do an arbitrary subset of the error handling

<mjs> that does seem useful for conformance checkers though

<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.

<Hixie> in practice it doesn't matter much

<anne> zcorpan_, I would say that it sets the namespace prefix xmlns to namespace bar

<anne> unless there's some good reason to have xmlns reserved in which case it would be "ignored"

<anne> anyway, as you can tell this isn't worked out yet, but this has less to do with the actual tokenization I think

<zcorpan_> anne: that would make the all other namespace declarations stop working

<anne> unless I'm seriously missing something here

<anne> oh right, ignored

<xover> The most common complaint on www-validator is that it reports a gazillion "bogus" (cascading) errors in some cases.

<zcorpan_> anne: are attributes tokenized the same way as in html5?

<zcorpan_> (but with more parse errors here and there?)

<anne> zcorpan_, yeah, not sure about more parse errors

<zcorpan_> anne: i thought it was a goal that any conforming xml5 document is also well-formed xml1.0?

<anne> no, the other way around

<zcorpan_> (perhaps ignoring text/xml and ascii)

<zcorpan_> oh

<zcorpan_> ok

<anne> same for xml1.1 hopefully

<mjs> it's Anne's idea for a dialect of XML with lenient error handling

<anne> XML without namespace well-formedness

<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

<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

<xover> anne: URL?

<anne> zcorpan_, as for "tools will safe us", conformance checkers can certainly indicate such boundaries

<anne> xover, there isn't much concrete yet

<zcorpan_> anne: hmm... ok. i'm not sure what i think about it yet

<anne> me neither

<anne> but for now I like this idea

<Hixie> i thinks tools are supposed to save us, not safe us

<Hixie> i don't think putting us into a safe would be helpful

<Hixie> :-)

<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

<Hixie> though some might disagree...

<xover> «Go on Hixie, get in there. There's a unconquered SGML bastion in there. Get in the darn safe!»

<zcorpan_> that's why xml 1.1 was ignored

<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

<zcorpan_> Hixie: anne suggested to do the same with xml5

<anne> no

<zcorpan_> now i'm confused

<anne> I specifically said that both well-formed XML 1.0 and XML 1.1 would still work in XML5

<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"

<anne> and that two different subsets of XML5 therefore will work in XML 1.0 and 1.1

<Hixie> e.g. some HTML5 works as XML 1.0, even

<Hixie> but not all HTML5

<zcorpan_> anne: right. there should not be subsets, conforming xml5 should be well-formed xml 1.0

<anne> I don't think it makes sense to disallow XML 1.1 as XML5

<Hixie> anyway

<Hixie> gotta go

<Hixie> ttyl

<zcorpan_> xml 1.1 is already ignored, and not used, so i do think it makes sense :)

<anne> anyway, my project, my call

<anne> people can later fuck it up in some WG :p

<zcorpan_> anne: you should talk to hsivonen about this too :)

<anne> i did

<zcorpan_> he was ok with xml5 allowing things that are disallowed in xml 1.0?

<anne> i don't think he was (strongly) opposed, but dunno

<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?

<zcorpan_> i'm just trying to help with xml5 becoming successful, i'm not working against you or anything :)

<anne> you can write backwards compatible HTML5 and you can write backwards incompatible HTML5

<zcorpan_> anne: difference with html5 is that existing parsers aren't drocanian

<zcorpan_> xml 1.0 parsers are

<anne> <map id>

<zcorpan_> <map id> is something i've suggested to get changed to <map name> :)

<anne> glad you're being consistent

<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)

<zcorpan_> am i not?

<anne> you are :)

<zcorpan_> phew :)

<zcorpan_> anyway, gotta go

<anne> see you

<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>.

<Lachy> how hard is it for people to understand that a spec without normative requirements is just a list of feature requests?!

<anne> I think some people rather like HTML4

<anne> same as last week?

<gsnedders> I guessed

<gsnedders> [that]

<mjs> not quite the same

<mjs> people arguing against compatibility and error handling are gradually losing their resolve

<gsnedders> and saying they'll leave

<gsnedders> ergh. everyone will have to make compromises along the way

<mjs> one guy said that, but he hasn't left

<mjs> he seems unable to state an actual benefit for draconian error handling though

<gsnedders> I've seen othes

<gsnedders> two, I think

<mjs> other than mentioning that he likes "Segmentation Fault" messages

<gsnedders> but they're fun! you have to work out their cause!

<mjs> personally, I'd rather not bring the power and flexibility of segfaults to the web

<gsnedders> me neither

<beowulf> i wonder how many people asking for draconian error handling have ever written xhtml for a big organisation

<mjs> or at all

<gsnedders> As I've said before, I think all those criticising what browsers do, and implement, should write a browser themselves.

<gsnedders> Users _don't care_ why stuff doesn't work.

<gsnedders> They'll ask you to make it render, even if it is illformed.

<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

<mjs> but not entirely invalid

<gsnedders> I think they just really under-estimate the complexity of it

<anne> it's hard to grasp the complexity of the web not doing work related to some browser

<beowulf> I think some people are overly idealistic about html

<gsnedders> there are a few people with the vision of the XHTML2 WG, not the HTML WG

<beowulf> even aside from the browser complexity side of things (which i know nothing about)

<anne> (even then it stays hard :))

<beowulf> ignorance is bliss

<mjs> so the current vote on adopting HTML5 is 91-4-2

<mjs> (counting concur votes w/ the current majority)

<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)

<beowulf> i was thinking, adopting html5 might have been better as something you had to sign up for in the charter :)

<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)

<beowulf> I might change my vote to no, I'd prefer it to be HTML BEOWULF

<gsnedders> stating a preference isn't really a valid technical argument :)

<gsnedders> myakura: HTML 4.01

<mjs> only one vote against the editors

<mjs> w/ no argument

<gsnedders> (though HTML 4.0 predates HTML 4.01, so calling it HTML5.0 would be better under that argument)

<mjs> I think ~1% dissent is pretty good

<myakura> that explains :)

<beowulf> myakura: maybe they see the WHATWG HTML5 as preceeding W3C HTML5, i dunno

<mjs> John Boyer used the phrase "cut and run" in his comments

<mjs> I wonder if he will advise us to "stay the course"?

<gsnedders> let me write something from an end user POV.

<gsnedders> of well. at least I have no further exams till Tuesday :\

<Lachy> I don't understand how people can argue that <sub> and <sup> are non-semantic.

<gsnedders> logic? we need that!?

<Lachy> I mean, it seems to be just an objection to the name because it has a presentational meaning

<Lachy> though, the names have semantic meanings too

<beowulf> what are people suggesting <sub> and <sup> be replaced with?

<mjs> it appears that <sup> and <sub> have several possible semantics

<mjs> although meaning is likely to be altered more severely by removing them than removing <i> and <b>

<anne> I think having catch all elements for several typograhpical conventions is a good a thing

<mjs> me too

<mjs> it seems better than forcing use of <span> for everything

<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.

<mjs> and better than inventing dozens of tags which might still not catch every case

<anne> (Whether it was a mathematical formula or some chemical structure for instance. Or something like 2nd)

<myakura> but not LaTeX ;)

<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

<Dashiva> Maybe we need HyperTeX Markup Language for the semanticists?

<anne> they have XML

<anne> and classnames and such in HTML :)

<zcorpan_> and docbook

<anne> docbook doesn't go far enough I suppose

<zcorpan_> docbook+mathml? :)

<zcorpan_> +their own custom language? :)

<zcorpan_> let's just have custom languages!

<zcorpan_> then people can use whatever semantics they want

<zcorpan_> and use xslt to convert it to html4 on the client side

<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

<Dashiva> I don't get how people can say <sup> is vague, while <em> isn't

<hsivonen> Philip`: I believe the use case for semantic math is that you could copy from the Web and paste into Mathematica

<hsivonen> Philip`: the existing way is putting Mathematica code in alt=''

<hsivonen> of course, making this use case product-independent would make more sense if Mathematica has serious substitutes

<hsivonen> (I'm not familiar enough with Maple to know if it is a substitute)

<beowulf> i don't get why anyone really cares about valid use of <em>, <i>, <b>, <strong>, <sup> or <sub>

<beowulf> or am i missing the point?

<hsivonen> beowulf: don't you see they are morally wrong?

<hsivonen> they being the elements

<hsivonen> (or perhaps I misunderstood the question)

<beowulf> i'm using the word morally as a clue to sarcasm, correct me if i'm wrong :)

<hsivonen> beowulf: no correction needed :-)

<beowulf> excellent :)

<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>

<gsnedders> according to HTML 4.01 there is no normative difference between all four :P

<Lachy> HTML4 is irrelevant

<Dashiva> That could be interesting in a debate

<mjs> Gareth Hay keeps saying he's leaving and ending the debate, but then he keeps debating

<mjs> I guess I should let him have the last word

<anne> ah, <HtML xmlNS=http://www.w3.org/1999/xhtml> is even cooler

<beowulf> make HTML l33t, <b0ldz0rz>

<gsnedders> anne: sense?

<anne> "A capacity to appreciate or understand"

<beowulf> i like schepers email from this morning

<anne> pointer?

<beowulf> geography bored me rigid

<beowulf> anne: http://www.w3.org/mid/463AF04F.1050608@vectoreal.com

<gsnedders> beowulf: I'm going to be sitting an exam on Tuesday having not completed the course :\

<anne> does indeed make perfect sense

<beowulf> gsnedders: physical, human or both?

<gsnedders> beowulf: both

<gsnedders> (yeah, the hiding thing doesn't work with me)

<beowulf> :)

<gsnedders> beowulf: the physical stuff I can do very well, the human stuff not so

<beowulf> gsnedders: ditto

<beowulf> my degree was in geology

<gsnedders> nor old enough to be

<anne> yaiks

<anne> zcorpan_, any chance you can e-mail me a zipfile or your tests?

<anne> zcorpan_, or maybe just publish one online somewhere (just for css/magic-body, btw)

<zcorpan_> anne: all or just the ones you fail?

<zcorpan_> anne: can they be sent to the bug directly?

<zcorpan_> anne: btw, all 003s seem to expose a scripting bug in opera

<zcorpan_> (except the declarative that is)

<anne> all, dunno, interesting

<zcorpan_> http://simon.html5.org/test/css/magic-body/magic-body.rar

<zcorpan_> (README.txt contains a table which lists which tests opera fails)

<zcorpan_> HTH

<anne> hehe

<gsnedders> we have a fatal parsing error, then we start parsing again to process the document as HTML 4.01…

<gsnedders> why have a fatal parsing error in the first place?

<Lachy> he doesn't understand that reparsing is a major performance hit, can have security issues, and...

<anne> browsers implementing that will have a disadvantage opposed to browsers that don't

<anne> so it won't happen

<anne> this was already pointed out several times on the mailing list

<anne> probably not worth repeating once again

<Lachy> he's living in Utopia, where all authors of HTML5 will ensure that their pages work before publishing

<anne> i don't think he is

<Lachy> he also fails to comprehend the possibility of an unencoded ampersand sneaking it, or something equally trivial, which would inexplicably break everything

<Lachy> I was going to ask him what it's like living there, but I don't think I'll be sending the mail

<gsnedders> the number of times I've committed code (not markup) into public repositories that causes parse errors helps make that point

<gsnedders> with more minor changes, you may not check that it works before pushing it

<Lachy> has anyone heard of Gareth before? Know what his background is and how much experience he has with web dev?

<anne> Doesn't matter

<gsnedders> None with actually parsing HTML, for certain

<Lachy> I know it doesn't matter, I was just wondering

<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?"

<gsnedders> it was in the context of a minor mistake

<beowulf> the point is that languages shouldn't be draconian in handling errors, they should try, try and try again to convey meaning

<hsivonen> gsnedders: can we reject everything said by people who make vocabulary errors? (depreciated... :-)

<gsnedders> hsivonen: a splling mistke?

<beowulf> maybe we need dialects

<gsnedders> hsivonen: I take it I said depreciated from that comment, though ;)

<beowulf> Philip`: at that stage we try a new language, not give up

<hsivonen> gsnedders: no, I meant in general

<gsnedders> hsivonen: ah

<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

<beowulf> oh, that was bad

<beowulf> "can't not" # very bad

<gsnedders> "First letter of sentenced not capitalised. Unable to process sentence."

<beowulf> (I also have opinions now, having read 100's of emails, go me)

<hsivonen> "Gareth Hay asked recently

<hsivonen> "Are you suggesting that HTML should allow tags to be written in

<hsivonen> any language ?", and I most certainly am. "

<hsivonen> I guess I'll give up now

<beowulf> is this your last post on irc?

<hsivonen> no. my last reply to philip taylor (webmaster) in that subthread

<Lachy> I should have guessed the role attribute would come up eventually :-(

<Lachy> (see John Foliot's latest post)

<zcorpan_> oops, seems like i responded to something that had a massive tree under it which i haven't read

<zcorpan_> so much for opera's tree view :|

<Lachy> zcorpan_, never mind, I've responded to heaps without reading whole thread. I've still got 212 on public-html to read

<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

<zcorpan_> great feature!

<zcorpan_> (the indicator that it is collapsed is cropped because the subject line is too long)

<Lachy> doesn't it have a +/- expander button next to it?

<Lachy> what other indicator would there be?

<zcorpan_> oh, right there is

<zcorpan_> it would say how many messages there are after the subject

<Lachy> oh, nice

<zcorpan_> could be but i don't get to see it very often... usually the subject line is too long

<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

<zcorpan_> Lachy: agreed

<xover> Anyone know if the Patent Policy implications of the WHAT WG submission has been dealt with?

<hsivonen> xover: which implications specifically?

<xover> The proposal only mentions copyright assignment; has it been vetted for Royalty-Free Patent Licensing as well?

<hsivonen> xover: as in patent searches?

<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.

<hsivonen> pardon my ignorance. how are normal submissions vetted?

<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.

<h3h> from what I gather that doesn't matter

<h3h> when the spec goes to call for comments any vendors must explicitly object to any content that is under their patent control

<h3h> and if they don't, it's free for use in the final spec

<h3h> Apple has already said they won't do that for <canvas> etc.

<h3h> (the above was gleaned from several list posts)

<xover> Hmm. Ok. So we assume it won't be a problem, but it hasn't been explicitly dealt with?

<h3h> it was explicitly addressed on the list. check the earliest archives...probably in the first 50 threads

<h3h> it's just more of the same

<xover> Yeah, too much noise to pick out the productive bits.

<h3h> I just drop in on Maciej's or Ian's replies every now and then to see what's going on :)

<hsivonen> xover: surely you aren't going to object on patent grounds?

<xover> No, no. :-)

<xover> If it was an actual problem I would, but mainly just to make sure it got handled.

<xover> I'm reviewing the questions up for vote against the Charter, among other things.

<xover> Trying to figure out which of my misgivings are for substantive reasons and which are just preference, subjective, etc.

<h3h> it's a semantically invalid argument if we're going to be picky

<schepers> xover, what issues are you concerned with?

<xover> Trying to figure that out, actually. :-)

<xover> I think at the base I'm concerned with the attitude and goals underlying, in particular, the “HTML5†submission.

<schepers> I can totally understand that

<xover> But I'm as yet undecided on whether or not there is anything in there that constitutes a substantive issue.

<schepers> I think they have made a very poor attempt at explaining why this would be a good idea

<schepers> the arguments have been, in tone if not in substance, "shut up and let us have what we want"

<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).

<h3h> I think good explanations have been made, but have been drowned out in confusion and misunderstandings

<schepers> h3h: I agree, there have been very lucid posts

<xover> Another concern for me is the navel-gazing quality of the arguments.

<schepers> xover: that's been on both sides

<xover> yes

<gavin> schepers: which "this" are you referring to above? the current vote for editor/starting point/name?

<schepers> gavin: yes, specifically taking the WHAWG proposal

<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.

<h3h> have you read the reasons given in the survey next to the "yes" answers?

<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

<xover> hsivonen: However, that was not the issue I was referring to.

<h3h> schepers: to be fair, it's asking whether or not the spec should be admitted for discussion -- reading it is not a prerequisite

<h3h> knowing the gist is, however

<schepers> h3h: I don't think that's realistic... in a way, it is a fiat, because of momentum

<h3h> I don't see it as fiat at all. the resulting discussions in this WG could invalidate everything in the current spec

<hsivonen> xover: it illustrates getting stuff done vs. discussing it in a committee

<h3h> fiat would be mandating its inclusion in the final spec somehow

<xover> hsivonen: Sure. But the WHAT WG does not represent the needs of the sum total of the web.

<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?

<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

<h3h> schepers: that's a completely separate question

<xover> hsivonen: And that realization has not been particularly prominent in their interactions with those who dissent.

<h3h> and Hixie doesn't resist changes to the spec when they're presented with a strong argument and real evidence

<gavin> schepers: I don't think it's fair to say that Hixie would resist any attempt to change the spec

<h3h> he's one of the most rational people I've had the pleasure of interacting with on specs

<gavin> schepers: he has been convinced to change things, and has said there are things he'd like to change

<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

<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â€.

<xover> schepers: I'm, as mentioned, as yet undecided on whether any of my misgivings represent actual substantive issues.

<schepers> fair enough

<schepers> xover: let your conscience decide, but also consider what the implications of a formal objection are, and if that meets your goals

<xover> Ugh. Anyone else occasionally getting the raw markup instead of cooked display for the ballot page in Safari?

<gsnedders> xover: yes

<xover> I should break out a packet sniffer and see wtf is going on there.

<mjs> 77 new emails since I went to bed last night (which was at 4 AM!)

<xover> Enjoy the firehose. Hope you were thirsty. :-)

<Zeros> I have 591 unread at this point

<gavin> I have 0 unread messages, but some of them haven't been read

<gavin> depends who they were from and what the subject was

<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

<Zeros> I need to figure out how to get Mail.app to group by subject :/

<Zeros> It's really hard to follow this when there's 380 emails and they go from topic to topic

<gavin> well, yeah, I don't delete them indiscriminately

<Zeros> The support existing content thread has the <font> thread all mixed in with it

<Zeros> heh

<Zeros> I guess I could just start reading them on gmail itself

<h3h> hooray Gmail

<gsnedders> Zeros: view -> organise by thread

<Zeros> gsnedders, oh they are organized by thread like that

<Zeros> But it doesn't group by subject line

<gsnedders> ah.

<Zeros> I don't know why

<gsnedders> someone who actually knows the subtle difference

<Zeros> :)

<Zeros> not sure, but what ever it's using it's a real pain

<Zeros> gsnedders, http://enfinitystudios.thaposse.net/personal/mailapp.png see what I mean?

<Zeros> that "thread" is 300 emails long, and it goes in and out of different subjects

<gsnedders> Zeros: I know what you mean

<gsnedders> Zeros: I use Mail.app myself

<Zeros> Is it doing that for you too?

<Zeros> mjs said his wasn't, so I'm curious what the difference is

<xover> mjs: You took me to task for such characterizations just the other day...

<mjs> xover: I don't mean it to be perjorative, entirely, though I somewhat disagree with such sentiments

<xover> `twas a friendly reminder is all... :-)

<xover> «You need two things on Usenet — a civil tongue and a thick skin.» - Steve Dorner

<xover> I am as mercifully equipped with the latter, as I am sadly lacking of the former. :-|

<xover> schepers: ping?

<schepers> xover: pong

<xover> Ah, mind if I take it to privmsg?

<schepers> feel free

<schepers> mjs: I thought you were being sarcastic about the linguistic prescriptivist/descriptivist comment on IRC, but I see know you were serious :)

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.98)

Succeeded: s/the screwy way you get/the screwy way one has to get/
Succeeded: s/is out/us out/
Succeeded: s/parsed/tokenized/
Succeeded: s/invalid/illformed/
No ScribeNick specified.  Guessing ScribeNick: hyatt
Inferring Scribes: hyatt

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Dashiva Hixie John_Boyer Lachy MikeSmith MrNaz ROBOd Roger Shunsuke Zeros Zoffix anne beowulf billmason cute dbaron edas gavin gavin_ gsnedders h3h hasather heycam hsivonen htmlr hyatt jdandrea kazuhito loic marcos mjs myakura olivier sbuluf schepers tH xover zcorpan_ zdenko
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2007/05/04-html-wg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)