HTML Working Group November f2f Day Two -- 9 Nov 2007

<anne> Karl: New technical contact for HTML is Michael(tm) Smith

<anne> [the audience goes mad]

<anne> Karl: [praises Mike some more]

story telling + testcases

<anne> On screen: "Testing: hard?"

Olivier Thereaux talking

screen say "your tag sucks"

<anne> also "Ranting: easy!"

followed by "Ranting: easy!"

<anne> OT: People already test, otherwise they couldn't rant about the impl sucking

OT: Invite people (ranters) to participate in testing.

<DanC_lap> link love

<anne> screen: "Leveraging the lazy Web"

Slide: Leveraging the lazy Web

<Hixie> right. well. if anyone wants to help me write the scripts to handle dynamic annotation of the html5 spec, i'm going into the lobby

<olivier> Michael?

hsivonen - I miss the point of using EARL ... why EARL?

OT: EARL is not a panacea, it's just [one] appropriate way

hsivonen - worried about the reputation system ... Subversion team says that people should not put their names on the code [for test cases?}

<Zakim> DanC_lap, you wanted to answer "why earl?"

<DanC_lap> for more on why earl and how earl:

<olivier> dom is coming now to showcase the mobile web test harness

<DanC_lap> GRDDL implementation report, built with EARL

<DanC_lap> never too soon to start testing

<olivier> anne, want to q+ to bring these concerns?

<anne> help, namespaces on screen

<ChrisWilson> i'm melting!

<anne> For the record: HTML is generated using print, not using a DOM

<anne> (in the python script that goes from EARL to HTML)

<Zakim> dom, you wanted to showcase test harness

Dom is chair of Mobile Web Initiative Test Suites Working Group

Dom describing Mobile Test Harness

<anne> http://www.w3.org/2007/03/mth/harness

<olivier> harness lets users either run full test suite, a single test

<olivier> ... or come back to the test suite and run only the tests not yet tested

<Zakim> olivier, you wanted to ask dom how you avoid spam/bogus

<olivier> dom: the results show how many people agree/disagree

<olivier> ... the power of many will/should show the actual result

<olivier> ... if after a while there is still disagreement maybe the test case is not clear or relevant

<olivier> dom: the goal of this was to build a nice report chart automatically

<olivier> ... these generally done by hand until now

<olivier> håkon: like the harness. we seem to have a big community that we could leverage

<olivier> ... but will there be an issue with having too many tests

<olivier> karl: you can just answer a few tests

<olivier> håkon: for a tester, completing the suite has a feel-good effect

<olivier> plh: we could have modules

<olivier> plh: can I change my answers?

<olivier> dom: you can use the back button

<olivier> plh: is the system really scalable?

<olivier> dom: number of tests doesn't affect the running of the test suite

<olivier> ... only the report table

hsivonen mentions the Mechanical Turk

<DanC_lap> yes! just like mechanical turk, hsivonen

<anne> or simply automate a bunch of tests using JavaScript

<DanC_lap> yes, automated tests are great too, anne

<anne> we already did that for html5lib tests

<olivier> dom: we can add these features to the system, it's still fairly young

<olivier> ... still fairly flexible

<olivier> plh: do you need an account?

<olivier> dom: no. and the system is stateless

<ChrisWilson> but then, maybe I'm just used to being spammed.

<DanC_lap> http://www.w3.org/Consortium/sup

<olivier> anne, I think I should have made your q+ an agenda+

<jgraham_> automated html5lib tests: http://html5.org/parsing-tests/testrunner.htm

<Zakim> anne, you wanted to say that I think we should discuss licensing, hosting, making tests, as opposed to EARL

<DanC_lap> RFE: mix in the "I agree to the W3C patent policy" ritual

<olivier> dom: the harness is open, public, talking about it is welcome

<DanC_lap> hixie is giving a course on testing in another time/space

<DanC_lap> on making tests, that is

<DanC_lap> let's look at http://esw.w3.org/topic/HTML/F2F

<fantasai> Ishida offers to talk about i18n issues; the i18n group is visiting this morning

<fantasai> Ishida: We haven't started reviewing formally yet.

<fantasai> Anne asks the i18n group for issues.

<fantasai> Henri: There are some requirements in the charmod model that we can't satisfy and meet our existing content compatibility requirements.

<fantasai> Dan wants proof

<fantasai> Henri: THere are some cases where I as a validator must ignore one of the checkpoints or my users will ignore me.

<fantasai> Addison says that this is an opportunity to teach web authors about how to handle char encoding properly.

<fantasai> Howcome asks for a summary of the issue.

<DanC_lap> well, no, I don't want proof; I want it recognized as a tension rather than a black-and-white impossible conflict

<fantasai> Addison: The issue is that there's a section on encoding detection for the page.

<fantasai> Addison: And the sequence has a part where we were concerned about the phrasing

<fantasai> Addison: Not because they're technically wrong, but because they may give people the wrong impression.

<karl> http://lists.w3.org/Archives/Public/public-html/2007Nov/0068.html

<fantasai> Addison: You have a phrase that says that Windows 1252 is the encoding for Western documents

<fantasai> Some discussion of the wording

<fantasai> Addison: we could do some work to support you

<fantasai> Addison: This windows-1252 seems to appear from nowhere. People don't know its relation to other encodings. We could provide additional references.

<fantasai> Anne: This is the parsing section for implementors, not for authors.

<fantasai> Addison: Implementors dont' necessarily know more about encodings.

<fantasai> Addison: For example, how do you know if you're parsing from a Western demographic?

<fantasai> Addison: We proposed some changes to the text.

<fantasai> Addison: We moved the recommendation to UTF higher and then added a note about the use of windows 12-52

<fantasai> Henri: this is the last fallback.

<smedero> I went ahead and opened an issue for this topic...

<DanC_lap> (is there an issue tracking TF member here? where does this live in the issues list?)

<smedero> http://www.w3.org/html/wg/tracker/issues/11

<fantasai> Addison: This is the last paragraph after everything, including auto-detect, fails.

<fantasai> Henri: That should be windows1252

<DanC_lap> proposed ACTION: addison and hsivonen to investigate HTML default encoding and windows1252 over beverage of choice

<Zakim> DanC_lap, you wanted to point out that anybody who wants it to work but worries about W3C servers can wish into the supporters program and to and to say that when I checked the

<fantasai> Addison explains that utf8 and windows 1252 can be differentiated with heuristics.

<fantasai> Henri says that that should be part of an earlier step

<fantasai> decided to move that discussion to after break and invite hixie

<fantasai> henri and addison will discuss

<fantasai> Anne adds Test licensing to 4pm slot

<karl> http://www.w3.org/html/wg/tracker/issues/11

<ChrisWilson> ^^^is the character encoding issue

<fantasai> Anne wants a W3C lawyer to attend to discuss licensing

<fantasai> DanC says that MIT has been approved

<smedero> (yeah I was *just* opening that issue before DanC asked for it... it is quite brief... but at least it is there.)

<anne> go DanC_lap!

<fantasai> break

<smedero> \

<dbaron> what room is hsivonen in now?

<anne> we're in the lobby

<anne> close to the exist, on the couch + chairs

<anne> room D was not useful

<mauro> anne, what do you mean room D was not useful? can I help?

<jgraham_> No chairs in D

<jgraham_> or tables

<mauro> what?

<smedero> you mean Ballroom B?

<jgraham_> Yeah B, not D

<karl> http://esw.w3.org/topic/HTML/F2F

<karl> GIG session at 11am

<karl> during the break

<anne> well, we're in B now

<anne> it's through a secret door

<jgraham_> mjs, organising tests is at 16:00 now

<anne> it was not about organizing

<anne> the wiki is updated

<karl> fantasai thanks for minuting

<mjs> I only see "HTML5 for Authors" at 4:30

<jgraham_> that's 14:30

<mjs> oh, that's 2:30

<mjs> There's "Tests: : Licensing, hosting, etc."

<mjs> cool

<anne> licensing is resolved apparently

<anne> The W3C is now fine with MIT

<jgraham_> :)

anne - was there any discussion of hosting?

<anthony> ahhh ok

<anne> MikeSmith, 4PM

hai

<ChrisWilson> PLEASE NOTE: Offline support is moved to 11:45, due to scheduling conflict. We can run slightly late and into lunch, or if people would prefer we can move it to 5:00PM

<anne> FYI: I can't attend from 2PM to 4PM having to attend the Web API WG meeting

<anne> (XMLHttpRequest level 1 and level 2 are discussed if anyone is interested.)

<Hixie> ChrisWilson: what was the conflict?

<mjs> I'm ok with either 5 PM or 11:45 AM

<ChrisWilson> Hixie - the schedule worked, except a bunch of people (including my co-chair) thought the instant gig was set for 11:00, not 10:00, and didn't discover this conflict until too late.

<Hixie> aah

<anne> Hixie, the "i18n people" want to discuss some issues with encoding detection around 11AM, any chance you join? Hopefully it doesn't take too long

<anne> I guess that would be now

<anne> hmm

<ChrisWilson> anne, would you like to have that technical issue discussion with a larger group? we can put it on the agenda, either later today or tomorrow. Or have an informal discussion over lunch?

<anne> it's just a few things, they haven't reviewed HTML 5 yet

<anne> (well, obviously some parts, but not all of it)

<anne> so informal is fine

<Hixie> anne: sure

<Hixie> anne: wher?

<anne> by the drinks, close to D

<Hixie> i'm looking after mike's laptop but once he gets back i can join you

<ChrisWilson> ok. It seemed like not only were they familiar with the current spec, but that they didn't have the same thoughts about specifying a definitive default for interop. Or maybe that was just my interpretation.

Hixie - sorry bout my laptop - thanks

<ChrisWilson> I don't see him.

oedipus - Marcos not in the room here

<Hixie> MikeSmith: np

<karl> guys: you should come here

<ChrisWilson> Yeah, this is the reprise of karaoke from last nite.

<ChrisWilson> :/

<ChrisWilson> Hixie, Janet just dedicated a stanza to you. :)

<smedero> I'm really digging the animated GIF on the tab/lyric page.

<hsivonen> http://hsivonen.iki.fi/charmod-checking/

<hsivonen> http://hsivonen.iki.fi/charmod-norm-checking/

<Hixie> ChrisWilson: aww

<anne> #i18n covers some of the i18n discussion

<Hixie> ChrisWilson: please convey my thanks

<anne> it's in room B and slightly more formal than I expected

<ChrisWilson> Ian, you're missing your dedication

<smedero> Ian may be wrapped up in the il8n discussion...

<mjs> Hixie: you're lucky to be missing it

<smedero> hahaha

<ChrisWilson> aww, now come on mjs. This is fine entertainment. :)

<anne> Can someone inform me why we need another ARIA discussion?

<ChrisWilson> The ARIA guys didn't feel the conversation had resolved. I wasn't there, Dan was busy at the time. Were you there, and can you summarize the conversation and conclusion for me?

<ChrisWilson> (brb)

<anne> I wanted to discuss naming, but the rest was more interested in discussing what ARIA is about it seems

<anne> I don't really want to discuss either of those as I think after the five discussions of an hour or longer I've had on this I think we should just bite the bullet and move on

<ChrisWilson> can you describe your bullet? :) (I know what ARIA is, how it works, etc.)

<ChrisWilson> how do you think it should be embedded into HTML (and XHTML, et al)?

<anne> I think we should not reuse role= because overloading that for both a low-level access API and general extensibility seems wrong. Using aria= seems better. And using aria-propertyname for the properties as that causes the least amount of trouble for everyone involved except for schema writers which should really be our last priority

<anne> and Henri said he was willing to make the schema

<ChrisWilson> it seems that perhaps aria-role: would be more descriptive? I personally agree about overloading role

<anne> so aria= has the advantage that aria-properties= seem like properties for what aria= says

<anne> aria-role= would look like the properties

<aaronlev> anne: i'm against making that change right now, it's not worth the work

<anne> and also make people think we're forking the XHTML role module, which we don't really want I think

<aaronlev> we're not overloading role, we're using it the same way

<aaronlev> darn i gotta go, be back in 10 minutes

<anne> no we're not

<aaronlev> anne: xhtml2 wg is fine with us using it this way, talk to rich

<aaronlev> they agreed to it today

<anne> role= doesn't seem at all related to aria-properties which is problematic I think

<aaronlev> bbiab

<anne> I think it makes more sense to have a consistent low-level API

<anne> "be back in a bit"

ChrisWilson: discussion on offline support is here in the music room at 11:45, right?

<Hixie> ia gree with anne on this, fwiw

Hixie - will you be able to join discussion about offline stuff?

<ChrisWilson> MikeSmith, yes

<ChrisWilson> Anne, I think you've highlighted why the ARIA guys wanted to have further discussion. If one more steel cage session resolves this issue, that would be a good thing.

<mjs> Hixie: wanna talk offline at 5?

<Hixie> we'll be coming shortlly

<anne> ChrisWilson, well, I need to know what will be discussed first I guess

<anne> ChrisWilson, but yeah, maybe we can do more of this funny discussion

<aaronlev> i can be around tomorrow, i guess a discussion is scheduled for then

<aaronlev> also rich is around today i believe

<ChrisWilson> 9am tomorrow in President's D.

<aaronlev> great

<aaronlev> xhtml2 minutes should have what was discussed

<aaronlev> but they anyway xhtml2 group is trying to sensibly accomodate html's needs now

<anne> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-offline.html

<aaronlev> anne: i can see your arguments are somewhat reasonable but it's a lot of work for everyone to make that change

<aaronlev> so i think it has to be a large enough gain to make it worth it

<aaronlev> plus it is still political

<aaronlev> i would really like to get past all this and do real work

<anne> i'm not sure how it's a lot of work

<anne> was adding support for aria-property a lot of work?

<aaronlev> anne: yes but it was worth it

<aaronlev> anne: i had to go find all the authors and get them to do the change, and not surprisingly many were confused

<aaronlev> their examples broke because they didn't get it, etc.

<aaronlev> and with the role change we'd also have to go change all the specs

<anne> no, we just merge this into HTML 5

<aaronlev> with the aria- change we don't need to change much in the specs, because it's just a different include mechanism

<aaronlev> anne: that's not good

<anne> but changing specs should be the least of our concern

<aaronlev> i'm just pointing out that there's a payoff requirement for the work

<aaronlev> i don't think html-wg is the right place to put it

<aaronlev> because html-wg isn't the right palce to decide what roles there are

<aaronlev> or what properties

<anne> that's already decided by the access APIs

<aaronlev> anne: no, we also drive changes to accessibility apis

<Hixie> aaronlev: we could implement both as a transition path

<Hixie> have role="" and aria="" for a while

<aaronlev> Hixie: we could, i guess

<aaronlev> but i just don't think it's worth it

<aaronlev> i mean if everyone's for it, i guess i have to do it

<aaronlev> but i think html should allow another group to control what the attribute values mean

<Hixie> well the problem i see is that we really _don't_ want the aria-related role to be overloaded with all the... features... of "the" role attribute

<aaronlev> specifically pfwg should do that

<anne> ok, sorry, I'm fine with that

<aaronlev> Hixie: which don't you want?

<aaronlev> anne: with what?

<anne> having the actual values etc. defined by the PFWG

<aaronlev> cool

<anne> although I'd like them to define the processing stuff way more carefully

<aaronlev> rich said that xhtml2 said today that other languages could use role and define their own processing, something like that

<aaronlev> we need to read the minutes i guess or talk to them

<aaronlev> so hixie doesn't that resolve your issue?

<Hixie> aaronlev: sorry in meeting can't really talk in real time now, will be slow

<aaronlev> np

<aaronlev> ChrisWilson: if that meeting could be at 10 then i can make it

<Hixie> aaronlev: role="http://this.is.a.long.uri/that/means#something-like-a-microformat" shouldn't have to interact with the low-level accessibility APIs like role="notify region" (or whatever it's called)

<aaronlev> Hixie: Hixie i don't want that either

<aaronlev> Hixie: for role extensibility, if we ever prove that we need it, which we might

<aaronlev> i'd say the author should be able todefine a short name for it

<aaronlev> and describe any new properties it has using a link to a json file, e.g. <link rel="ARIA" href="buddylist.json">

<aaronlev> ... if we get that far, the role would like like

<aaronlev> role="buddylist listbox"

<Hixie> aaronlev: i don't understand how the author could extend an MSAA API

<aaronlev> with listbox being the fallback for older software that doesn't know how to process the json or know what buddylist is

<aaronlev> Hixie: we have created IAccessible2 which is a sert of interfaces on top of MSAA

<aaronlev> we have loosly spec'd object attributes now in all accessibility apis, for name value pairs

<aaronlev> and we can invent new interfaces

<Hixie> aaronlev: right but that's UA-level innovation, not author-level

<aaronlev> Hixie: the UA innovation would not be to create enumerations for the new role

<aaronlev> Hixie: the UA innovation would be to describe what the role inherits from, what it's properties are, the types for those properties, whether changes are relevant for presentatioin, and the localizations required

<hsivonen> I still very sceptical about authors minting new roles

<aaronlev> i've spoken with several screen reader vendors

<aaronlev> this is not really a problem

<aaronlev> it uses inheritance for one thing, so you aren't wrong if you use the fallback mechanism

<Hixie> you'll have to explain to me how this works

<aaronlev> basically the AT can choose to look at the standard role, which is from the known set in MSAA/ATK

<hsivonen> I expect this to require something like microformats.org for AT roles

<aaronlev> or to look directly at the role string, in case a newer version has support for a newer role

<aaronlev> or it can look at the object properties tat describe what to do with the new role

<aaronlev> you can also script the AT to have special functionaility for a custom role

<aaronlev> this is like JAWS scripts for the desktop now

<aaronlev> only in this case the app is a web page

<aaronlev> the object properties describe how to present a text version of the object and its properties and how to present changes to those properties

<ChrisWilson> Do we still need a 4:00PM discussion of Tests, licensing/hosting?

<aaronlev> so there are 3 ways the AT can handle it: 1) just fall back, 2) special code for new role, 3) use role+property description

<aaronlev> and 2 can be either in core AT or in AT scripts

<ChrisWilson> aaronlev - can perhaps you, Hixie anne and I share a table at lunch and discuss this? I'm trying to understand what we can/need to get out tomorrow's discussion

<aaronlev> ChrisWilson: i didn't come in today, unfortunately

<aaronlev> i can be avialble for a conf call after lunch

<aaronlev> ChrisWilson: or catch rich schwerdtfeger

<ChrisWilson> ok, i'll try to catch Rich

<oedipus> ChrisW: Rich is in #xhtml

<ChrisWilson> If you're around on IRC after lunch, I'll let you know scheduling.

<ChrisWilson> thanks oe

<oedipus> np

<ChrisWilson> er, oedipus

<oedipus> you can call me oeddie

[lunchtime]

<aaronlev> autocomplete would be better with brain input and machine learning

<Lachy> [dinnertime] ;-)

<oedipus> there are some STRANGE autocomplete implementations out their

<aaronlev> :)

<oedipus> duh, there

<aaronlev> not serious, in case anyone is worried

<oedipus> i just found out that in the google search box, a dropdown list appears when one begins to type -- same thing at ask.com -- which i discovered through sheer clumsiness (blind luck)

<oedipus> now that's a case where ARIA would help -- it would at least tell me that a dropdown was there

<ChrisWilson> reconvene at 1:30.

KevinLawver - where you?

<KevinLawver> MikeSmith - right outside the meeting room talking to glazou

<KevinLawver> Are we starting?

anne and ChrisWilson talking ... the rest of us are still digesting our baklava

<KevinLawver> on my way...

<hsivonen> Hixie: which session will you be in?

<hsivonen> Philip: in Opera?

<Philip> hsivonen: Yes

<Philip> Well, it's not really a cube, because it has some triangular holes in the side which shouldn't be there

<Hixie> hsivonen: i'm in versioning

[waiting on Chris to get started]

<justin> http://sitesurgeon.co.uk/tables/

[Chris plugs in to projector]

<scribe> Scribenick: MikeSmith

CW: So ... versioning.

Slide from Chris: Once a web developer has written, tweaked and debugged their page to get it to work across browsers, the definition of "correct behavior" is "my page still works".

CW: Quirks mode is no longer that popular ...
... back [sometime in the past] we found only 1 out of 200 sites that were in strict/standards mode ...
... out of top 200 web sites ...
... but did it recently and found ...
... that 99 out of 200 were in strict/standards mode ...

IH: 3 modes in most browsers: Standards, Almost Standards, and Quirks

<fantasai> IH: where Almost Standards is Standards with the images-in-tables quirk

<fantasai> IH: Using the algorithm in HTML5, about 9% trigger Standards mode, ~20% trigger Almost Standards

<hsivonen> Hixie, I see a G4-compatible power cord on this side of the table

IH: definitely a trend toward standards mode

CW mentions child-selector hack

<myakura> explaining the 3 rendering modes http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing

scribe: which depended on a certain CSS feature being not-supported in IE ...
... but after they fixed IE by adding that support, it broke all pages that rely on that hack ...

CW: people use library/frameworks that fix these problems for them ...
... so they don't themselves know what specific problems exist ...

fantasai: How many problems are in CSS and how many in HTML?

CW: in IE7, vast majority were in CSS

fantasai: so why not put a version switch in CSS

ChrisWilson: right now, we have a switch per-document

travis: CSS has this DOM appendage ...

<KevinLawver> The other problem is that the CSSWG has been against any form of versioning in the spec.

ChrisWilson: hard part is figuring out how to interop ...

<jgraham_> http://james.html5.org/tables/table_inspector.html

mjs: using the term "Super Standards Mode" is misleading here, because what it sounds like what you want is an unbounded series of quirks mode ...

<fantasai> mjs++

mjs: Would it not be better to have an IE-specific switch?

ChrisWilson: yeah, but it would need to be opt-in

plinss: I think everybody agrees your (ChrisWilson) logic is sound, withint your realm

<fantasai> TravisLeithead: What if Firefox was in this situation?

<fantasai> TravisLeithead: What if they were faced with making a change that would break a large number of pages. Wouldnt' they want a switch?

<fantasai> Hixie: I don't think we're deciding here whether a given browser should have its own set of switches.

<fantasai> David: I don't think we'd make a decision that compromised the ability of new browsers to enter the market.

<fantasai> Hixie explains that if each version of the dominant browser introduces a new mode that web sites can rely upon never to change, a version of the browser many years from now will have to implement 15 different layout modes

<fantasai> ... each full of undocumented bugs, and this makes it nearly impossible for a new browser to be created that is compatible with existing content.

<fantasai> chris and hixie discuss how authors check their sites and develop pages

<fantasai> Chris: we're not expecting other browsers to get content that is written for those 15 compatibility modes

<fantasai> KD: I don't think any of these problems you're discussing have anything to do with HTML version numbers.

<KevinLawver> +q KevinLawver question about how long this is actually a problem...

<Zakim> karl, you wanted to ask if a version attribute will create issues

<fantasai> Molly joins

<hober> fantasai: exactly. "author signaling to MSIE to use mode X" has nothing to do with "author signalling which release of the HTML spec she was authoring to"

<fantasai> Hixie: I think we understand your position. What are your goals with this discussion?

<fantasai> Chris: I think I'm missing a lot of the subtleties from other points of view.

<fantasai> Chris doesn't think having the spec reflect reality and reality reflecting the spec is true (?)

<Lachy> ChrisWilson, Authors are not going to want to require a permanent opt-in that needs to be updated every time a new IE ships. We need to develop a solution that let's us phase out the requirement for an explicit, IE-only opt-in over time.

<fantasai> Hixie brings up again David's point about the multiple quirks modes making it inordinately difficult for new browsers to enter the market.

<fantasai> Hixie: I don't think you understand the level to which we are scared.

<karl> KevinLawver, just do "q-"

<fantasai> Chris explains that he doesn't want the spec to be copying all of IE's problems

<fantasai> Chris: If FF and Opera do something reasonable and interoperable, we want to do that, not copy the insane bugs in IE

<karl> with Javascript, people relies on User Agent strings. Shall we remove them?

<fantasai> Hixie asks a question I couldn't hear

<fantasai> Hixie: The model you follow intentionally with IE7 of basically praying that people will fix their pages and finding that about half the people fix their pages

<fantasai> Hixie: is the model that other browsers follow.

<fantasai> Chris: Well, you saw what happened with our market share.

<fantasai> Hixie: I think the rest of us are ok with that.

<mjs> I don't think IE's market share is falling due to fixing too many bugs

<fantasai> Chris goes back to his argument that HTML version numbers will fix his problem.

<Dashiva> If so, because they fix workaround bugs before they fix the bugs they work around

<fantasai> Hsivonen: The approach that Apple took with the problem that content is written for certain UAs is that they made the UA string look close enough to the Firefox string that the sites that sniff it think it's Firefox

<fantasai> Hsivonen: and added other stuff so that statistics and later code can pick up on its existance.

<fantasai> Hsivonen: Are you planning a similar approache for IE7?

<fantasai> Chris: Not everyone is using UA sniffing to do that.

<fantasai> Chris: They might be using conditional comments, or CSS hacks.

<fantasai> Chris: The other problem is that UA string parsing is not uniform.

<fantasai> Chris: E.g. we're super-scared when we hit two-digit version numbers.

<fantasai> Chris: A bunch of people will detect us as IE1

<fantasai> Hakon: I think part of the pain you're feeling is due to not updating often.

<fantasai> Hakon: We develop continuously

<fantasai> Hakon: We release often

<fantasai> Hakon: The pain is constant, but it is not a severe pain.

<fantasai> Hixie: Release early and release often should help a lot with this problem.

<fantasai> TL: How many desktops still have Firefox 1.5 on them?

<fantasai> Hixie: Very few. Because the update system is good.

<karl> hmmm strategies of breaking stability for avoiding people developing for bugs

<karl> break the habits

<karl> or more about not creating habits

<fantasai> TL: We will be continuing to service the old browser with its bad quirks for years, due to its deployment in industry.

<karl> Rousseau. The only good habit for a child is to not get any.

<fantasai> TL: Forcing someone's corporation to adapt to an ever-changing platform is a tough choice

<fantasai> TL: I guess it's why we're in favor of the opt-in

<fantasai> TL: If we guarantee that their old content will work when we redeploy, it's much safer.

<fantasai> Hakon: This was tried when quirks mode was introduced.

<fantasai> Hakon: Those who went into standards mode, opted for standards.

<fantasai> Molly: Most of the doctypes out there are not chosen by people. They're generated by authoring tools. The authors don't know that they opted in.

<fantasai> Chris: Whether or not they opted in on purpose, they were opting in to something that meant the same for all browsers: give me the right behavior.

<fantasai> Chris: I think the thing that concerns me is that we'll have to end up do ing an opt-in that is IE-specific.

<fantasai> Chris gives an example of author choosing IE9, or something, I couldn't tell

<fantasai> Hakon: So you're asking for a continuous series of opt-ins

<fantasai> Chris says something convoluted

<PIon> How many desktops have FF1.3? Maybe, Boeing, say, is reluctant to change--we were told that.

<fantasai> Chris: I don't know that we'll be done with only one more switch.

<hsivonen> Chris asked for a way to date your understanding of standards

<fantasai> Chris: If a year from now, people start writing HTML5 .......

<fantasai> Hixie: That's a reason not to have a version switch in HTML. The cycle of HTML is much much greater than that of a browser.

<hsivonen> gavin, Travis from MS

<fantasai> Hixie: I honestly think it will take at least 10 years to standardize HTML.

gavin_: TL is Travis Leithead from MS

<fantasai> Hixie: HTML4 which was 9 years ago still isn't done.

<fantasai> Hixie: Even if it's 5 years, it's still longer than browser releases.

<fantasai> Hixie: That's the longest you've gone, and by your own admission it's too long.

<fantasai> Hixie: I don't think an HTML version switch will solve your use case.

<fantasai> Chris: Here's the case I'm worried about.

<fantasai> Chris: We have to do opt-ins to make sure we don't break content today.

<fantasai> Chris: Simultaneously HTML5 is under development, and eventually will get stamped as a standard.

<fantasai> Chris: And at that point content will be written that is stamped as HTMl5.

<fantasai> Chris: At some point that content will reach a threshold, say 20%.

<fantasai> Chris: After that point, we can't make content break. So we

<fantasai> 'll need an opt-in switch for the next version of IE

<fantasai> Elika brings up again that HTML version switch isn't what Chris is looking for.

<fantasai> Chris repeats his arguments

<fantasai> Hixie: the problem is this.

<fantasai> Hixie: The idea of the spec is that you implement it once, and it will work for the overwhelming majority of content.

<fantasai> Hixie: it is impossible for all content to work, because some of that content will be written for a specific version of a specific browser.

<fantasai> Hixie: But we can get the overwhelming majority.

<fantasai> Hixie: My goal for the spec is to write a definition that if you match the spec, you'll have a browser that will handle the overwhelming majority of content.

<fantasai> Hixie: You won't handle content that is deeply IE-specific, but you'll handle the overwhelming majority of content.

<fantasai> Hixie: All browsers can have their own private extensions, that's independent of this;

<molly> --q

<molly> thanks Karl

<ChrisWilson> Elika: why can't you do opt-out to IE-version-specific behavior instead?

<fantasai> Molly: This is a difficult core issue that I'm experiencing as someone who works between vendors, specs, and workers of the wild web.

<fantasai> Molly: We cannot, whatever solution we come up with, we cannot expect that authors will be able to take on the responsibility for adding the switch.

<fantasai> Molly: Let me give a case scenario. You're company X and you hire web design company B to do your stuff. THey're done, they ship it to you.

<fantasai> Molly: Then suddenly it breaks.

<fantasai> Molly: The masses are not where we are. That's just a fact.

<fantasai> Molly: This is not opt-in.

<fantasai> Molly: They don't get it.

<fantasai> Hakon: Shouldn't we expect that much?

<fantasai> Hakon: I would expect that when you put a declaration at the top, either there is some thinking either on the part of the author or on the part of the tool vendor.

<fantasai> Molly: You can't trust that.

<KevinLawver> Wouldn't that then put the onus on the tool vendors? Where's Steve Zilles?

<fantasai> Hakon: So how do you trust versioning?

<fantasai> Hakon: How does that solve your problem?

<fantasai> Molly: I don't know.

<fantasai> Karl: We're getting mails from people threatening to sue W3C because of the doctype

<fantasai> Molly: we can't trust authors to do the right thing.

<fantasai> Molly: There are huge gaps in their education.

<fantasai> Hakon: I think we understand. But since versioning doesn't solve that problem, it's not relevant to this discussion.

<dbaron> Molly says she's objecting to requiring authors to opt in

<fantasai> Chris: I'm not sure you understand what the tool has to generate.

<fantasai> Chris: If our tools don't generate work in IE, we have a problem.

<fantasai> Chris: So we could have a tool that generates a switch that locks us in to the current version of IE.

<fantasai> Chris: The problem is that we're proliferating that switch.

<fantasai> Elika: So you want to generate an HTML version number that will match and trigger an IE layout mode.

<fantasai> Chris: yeah

<fantasai> Hsivonen: So wouldn't it make just as much sense to use an IE version number or a datestamp?

<karl> http://www.google.com/search?num=20&hl=en&safe=off&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=meta++creationdate+content+name&spell=1

<fantasai> Peter explains scenario that an HTML5 document is written for IE8

<fantasai> IE8 has bugs, so author makes some hacks.

<fantasai> Then IE9 comes out with fixes for those bugs in HTML 5

<karl> already 3 ways

<fantasai> It's the same standard, different behavior in IE

<fantasai> Peter: You'll need to add addition atriggers to get the right behavior for HTML5 in IE9

<fantasai> etc.

<fantasai> Peter: What you want is the author to say "I made this page for HTML5 and IE8".

<fantasai> Chris: If we could get authors to say that, that would be great.

<fantasai> David Baron: Hacks like the child-selector hack are bad when targetting the current version of a UA. They're fine for old UAs.

<fantasai> Peter: There is no perfect solution.

<karl> rm -rf web.*

<karl> let's start fresh

<Dashiva> karl: Isn't that xhtml2?

<oedipus> zakim?

<fantasai> Peter: Putting a version in the HTML doesn't necessarily line up with putting version sin browsers

<kazuhito> FYI: http://www.webstandards.org/2005/11/27/pandoras-box-model-of-css-hacks-and-other-good-intentions/

<KevinLawver> The problem is that the hacks became ingrained because we were stuck with IE6 for so long. Doesn't this problem go away when IE6 does?

<fantasai> David: So, I think trying to solve this in anyway is potentially more dangerous, potentially creates a bigger problem than what we're trying to fix.

<fantasai> Peter: But ignoring the problem isn't making it go away.

<Zakim> ChrisWilson, you wanted to talk about tools

<hsivonen> dbaron++

<ChrisWilson> (done)

<fantasai> Peter: There has to be a solution.

<hober> KevinLawver: assuming IEN release cycles are shorter than the 6-to-7 one, sure

<oedipus> implementors are constantly asking for users to justify their concerns and use cases -- where is the "proof" that what crude tools we have at our disposal are the products of user-driven demand, rather than the product of convenience and perceived market-advantage on the part of implementors?

<oedipus> there are three layers of users being addressed by HTML5: developers, implementors/authors and end-users, and end-user concerns must be accorded the bang important in this cascade -- not the artificial marketplace created by individual developers which limits the choices available to implementors/authors, and hence compromises the user's ability to utilize the native mechanisms of a markup language, due to the restraints imposed upon the user by developers

<ChrisWilson> oedipus?

<fantasai> David: But there doesn't have to be a solution that creates a bigger problem than it fixes.

<KevinLawver> hober, I think we have that commitment from Mr. Wilson and crew.

<ChrisWilson> thx, just a sec

<fantasai> Peter: We all want to get to the point where everyone implements the same standard interoperably.

<fantasai> Hakon: I don't see how extending the matrix will make it smaller.

<fantasai> Chris: I'm going to have to extend the matrix anyway. I want to make the default over time the stuff that we really want, and the stuff that's IE8-specific, IE9-specific goes away

<fantasai> Hakon: Every other switch that we've introduced in the past, we haven't been able to get rid of.

<fantasai> Hakon: If we had N switches, and we add another one, we have N+1

<PIon> How about considering (thinking about) how natural language handles the same problem of changing languages and vocabularies, changing readers and their educations, and changing dictionaries, contexts and uttterance types?

<KevinLawver> oedipus++

<fantasai> Hakon: We had ua strings, and then we added quirks mode.

<fantasai> Hakon: But quirks mode didn't make ua strings go away.

<fantasai> Hakon: I don't see versioning making either of them go away.

<fantasai> Chris reads oedipus' quote

<ChrisWilson> oedipus, what did you mean by "and hence compromises the user's ability to utilize the native mechanisms of a markup language, due to the restraints imposed upon the user by developers "?

<ChrisWilson> I think you're saying "users have to win"?

<oedipus> there are many things in HTML 4.01 that were added for very specific reasons, but weren't supported

<ChrisWilson> is user == web developer or == end user?

<oedipus> end users have to win -- that is ultimately ALL our target audience --

<molly> oedipus +++

<ChrisWilson> ok. Thx.

<oedipus> tools are made for peoples' use, not the other way around, is what i'm trying to say

<hsivonen> oedipus, added for reason X doesn't mean that it solves problem X

<ChrisWilson> Any further points on this discussion? or can we move on?

HTML5 for authors

<oedipus> hsivonen, but when you have 2 groups (UA devs and assisstive tech devs) waiting for the other to implement feature X, and one can't until the other does, that doesn't mean reason X DIDN'T solve problem X

<fantasai> Karl: In the beginning the spec was only for implementors. Slowly people accepted that parts of the spec were for authors, explaining requirements of HTML5 for authors.

<fantasai> Karl: But that part of the text is incomprehensible to normal human beings.

<fantasai> Karl: Putting something understandable in the document will confuse the impelementors, or will be hard to understand for authors

<fantasai> Karl: So we need a separate document for authors.

<fantasai> Karl: How will we do this?

<fantasai> Ben: I support that we need to help authors with this.

<dbaron> (Ben == Ben Millard)

<fantasai> TL: We're seeing the same problem, authors need to search the web to see e.g. what element can be contained in what.

<fantasai> Tl: We need to write this.

<fantasai> TL: We also need to get this information to the authors.

<fantasai> Molly: I think we can do that. It's very important that we make very clear documentation. Once we have quality stuff, I think getting the word out is less of a problem.

<fantasai> Scott: Going back to the versioning discussion for a bit -- we're having problems getting authors to write these things, but when did we ever tell them to do it?

<smedero> done

<smedero> (or in progress :) )

<fantasai> Karl: First we need to extract the requirements

<fantasai> Karl: extract the content models

<fantasai> Karl: Then write scenarios explaining these.

<fantasai> Karl: One person can't do everything for this kind of document

<fantasai> Karl: So I would suggest we define a kind of template

<fantasai> Karl: For each element, you have to give this information, this is content model, here are two examples, here is reference material.

<fantasai> Karl: It would be good if those who can reach out to authors put this information where authors will find them

<Dashiva> PIon: do q+ to ask bla bla bla

<oedipus> scott, what about http://www.w3.org/TR/ATAG10 and http://www.w3.org/TR/ATAG20 in conjunction with http://www.w3.org/TR/WCAG10/ and http://www.w3.org/TR/WCAG20/

<fantasai> Molly: I think if we create a bullet list of things the author needs to do, that would be great

<fantasai> Molly: Like you said, before we didn't communicate what we wanted authors to write

<fantasai> Molly: Many people aren't at a good level of understanding of standards. it's improving over time.

<fantasai> Molly: HTMl5 is a great opportunity to improve that.

<fantasai> Karl: We should also consider the question of style. Authors can't read and understand the w3c documents

<fantasai> Patrick: We should write a Primer

<Dashiva> (Most w3c primers aren't exactly easy reading either)

<fantasai> Patrick: other working groups have a similar set of parallel documents: a very dry spec and a primer

<fantasai> Molly: I think the issue is that we need to understand our audience.

<fantasai> Molly: Implementors need one language.

<fantasai> Molly: Authors need a completely different language.

<fantasai> Molly: and sometimes vendors need yet another language

<fantasai> Molly: If there's anything I can do to bridge into author-land, that's what I'm here for.

<fantasai> Molly: vendors = tools authors, system technology vendors

<fantasai> Karl: validators

<fantasai> Molly: CMS developers

<fantasai> TL: A third tier is the garage programmer, very very simplistic view with lots and lots of examples.

<fantasai> TL describes a recipe book, almost. I want to make a chat program, I want to make a forum.

<fantasai> Kevin: This is why we have people like Molly and Eric Meyer

<fantasai> Kevin: W3C doesn't need to provide every single application and best practice.

<PIon> Is it not expected that the literature around the spec will evolve as it has for earlier HTML specs?

<fantasai> Kevin: The primer should be short, sweet, from what you know now to what you need to know

<fantasai> Karl: How do we organize the main primer and how do we link to best practices, e.g. on the wiki

<fantasai> Elika: I think you should put the whole thing on the wiki

<fantasai> examples: Mozilla wiki, php wiki

<fantasai> Yahoo and BBC publishing best practices

<fantasai> Molly: A lot of large organizations will be helpful in bringing good communication

<fantasai> Molly: We need to facilitate that effort. It's almost like a liaison role

<PIon> A wiki is a fine example of a new style of channel that might be used in the new situation here. It should be as much as possible actually using the technology being explained.

[MikeSmith stops by the HTML Authoring session and notes there are 20+ people in attendance]

<fantasai> Elika: A lot of large corporations need to develop good documentation on best practices, etc for their own web developers. If they collaborated, they'd each get more out of it.

<fantasai> Elika: This is similar to Mozilla: HP, IBM, Sun each had their own OS and needed a web browser. Instead of building a new one, they contributed to the mozilla project and ported it to their OS.

<fantasai> Elika: Our role, like the Mozilla Organization, would be to facilitate that coordination

<fantasai> Molly, Karl: We should form a liaison group to do that.

<fantasai> Karl: What does AOL use?

<fantasai> Kevin: Drupal. Or a wiki.

<PIon> You could perhaps start an XG of people interested in writing about the new HTML situation.

<fantasai> Kevin: I had a conversation with Kai from Mobile Web Best practice about dropping the M and making it just Web Best Practice.

<molly> Kevin +++

<fantasai> Kevin: people in my world don't understand the difference between the spec, the impl, and the best practices around that.

<smedero> I'm having trouble finding the messages from public-html but it was said that the JAWS and other companies/group implementing AT technology have been invited to the W3C process over and over... and yet they aren't participating. It would be nice to at least understand why they aren't... I mean maybe they feel there are serious legal concerns or ??? but I think to the common working group member - their silence on AT issues in the HTML5 spec defies logic.

<fantasai> Kevin: Best practices bubble up. And they change.

<molly> smedero I've experienced that as well, and do not quite understand it

<fantasai> Kevin: The best practices when the Zen Garden came out are not the same as they are today.

<ChrisWilson> 1 hr

<oedipus> smedero, they have a shortage of bodies -- they are relying on stadards harmonization or else they are busy writing custom scripts for individual applications

<oedipus> make that "standards harmonization"

<fantasai> Molly: What I'm thinking is finding those people that are interested in sitting and listening and working with the HTMLWG

<fantasai> Molly: and have a conversation, working on a document, and put it out in the wild

<fantasai> Molly: and then the best practices bubble up

<fantasai> grammatically-speaking

<oedipus> molly, there is the open source a11y project: http://www.oatsoaft.org/ - and the NVDA project (received mozilla grant)

<fantasai> Kevin: I love the ideal, but I'm not convinced...

<fantasai> Kevin: People have more good intentions than they have time.

<fantasai> Ben: The i18n team has been writing faqs etc on character encoding

<oedipus> smedero & molly, another challange for small AT companies is supporting multiple versions of a particular operating system

<fantasai> Molly: the i18n group's documents are considerably more clear than the rest of w3c stuff, for a topic that is much more obscure than other w3c technologies

<KevinLawver> primers and best practices are non-normative.

<oedipus> smedero & molly, not that i don't personally think that they have an excuse -- if they helped push for harmonization, things might be a good deal easier

<KevinLawver> hsivonen, that's why there will be tech editing for the primers.

<fantasai> Hsivonen: there's a risk that the best practices will include recommendations that don't really make a difference

<fantasai> Hsivonen: and the author has no way to know if fixing that is a waste of their time.

<fantasai> Karl: It's not about forcing, it's about suggesting.

<mauro> A List Apart's article on How to Read W3C Specs

<KevinLawver> Zaxim, +q kevinlawver to ask about w3c's "purpose"

<olivier> it's q+

<ChrisWilson> :_

<ChrisWilson> :)

<molly> why does kevin remind me of arnold horschak at the moment?

<KevinLawver> ooh ooh ooh, Mr. Kotter!!

<fantasai> Hsivonen explains that one group gets their practices enshrined in W3C document, and another group that does differently but doesn't break anything doesn't

<Zakim> kevinLawver, you wanted to ask about w3c's purpose

<dbaron> I think there's a difference between best practice and convention.

<dbaron> Documenting convention is fine, but you shouldn't call it best practice.

<fantasai> and now they're against the W3C best practices, and have to waste their time to fi their stuff

<fantasai> Kevin: Is this the W3C's role? We can't as the HTMLWG answer this question. this goes to the tag or ab or ac to say we are going to get into documenting best practices and stand behind them and say this is what it means to be professional

<fantasai> Molly: The issue here is critical. As former group lead of WaSP, I know that it is impossible for volunteer organization to play the role of "we are best practices".

<fantasai> Molly: Jeffrey Zeldman, who is looked upon as being next to God wrt standards, said "what problem are we facing in web standards, I see no problem, as long as we have xhtml and css2 we have no problem"

<fantasai> Molly: And that's just dumb

<fantasai> Molly: We need some quality assurance. We need to shift [to where??]

<fantasai> Molly: making best practices happen

<fantasai> Molly: simplified, clarified information that is separate from the specs that is not only published by W3C but also extended into the community

<fantasai> Molly: Say this is what we have studied as a problem.

<fantasai> Molly: This is a critically missing piece

<KevinLawver> (i'll do this in IRC so we can get to the queue) I'm not saying it shouldn't happen at all. Just that this needs to be an effort in the W3C as a whole to provide the bounds.

<fantasai> Patrick: I'm all in favor of educational documentation, but people have to figure out for themselves how to do it.

<Zakim> MichaelC, you wanted to say W3C specs usually are more successful when somebody markets them, Best Practices is one good way to do that

<KevinLawver> @pion The best practices come out of people "figuring this out for themselves"

<fantasai> MichaelC: I agree with Molly, W3C Specifications are more successful when someone markets them. I think a lot of W3C specs have suffered from lack of marketing.

<fantasai> MichaelC: In the case of HTML this is really important. If the developer community understands the spec, they will demand implementations.

<fantasai> MichaelC: I'm not going to advocate for a mechanism: best practices is one of them.

<fantasai> MichaelC: I don't care if W3C does the marketing or someone else, it must get done.

<molly> MichaelC +++

<fantasai> David Baron: I think there's a difference between best practice and convention, and it's fine to document each one, but you shouldn't label convention as best practice.

<fantasai> Molly: I agree, that's why we want liaison with the working group.

<fantasai> Molly, Justin: Yeah, we need an alternative to Jeffrey Zeldman declaring his conventions as THE way to do things.

<Zakim> kevinlawver, you wanted to ask about personality cults

<fantasai> Kevin: If it's just part of one working group, especially this one, there's still a danger of this becoming a personality cult.

<PIon> @KevinLawver quite so; I would worry that a spec has to be written here, and indeed a language is still to be finally developed; not all 300+ persons in the WG can or will be able to contribute to that.

<fantasai> Kevin: We do have these cults, and there's sometimes there's a lack of critical thinking. We can't let this become a personality cult.

<fantasai> Molly: I suggest we take this off the HTMLWG, and talk with the Architecture group and see if a liaison/QA group is something we need to revisit in this time and age.

<fantasai> Olivier: One thing, if you want to avoid the cult of personality, then maybe having it under the umbrella of W3C

<fantasai> Olivier: Second thing, the TAG won't care. That's not their problem.

<fantasai> Molly: They were interested enough to come to me.

<fantasai> Olivier: It would take awhile for this to go through the whole process. I think the HTMLWG has a chance of making it happen.

<fantasai> Olivier: If you're waiting for Members to submit, vote, charter, it will take years.

<fantasai> Molly: So should we create a new group with this..

<fantasai> Elika: Task force. Make a task force.

<fantasai> Elika: I would sign up for HTMLWG to join that task force.

<fantasai> Molly and Kevin raise their hands.

<Zakim> kevinlawver, you wanted to suggest a guerilla + "proper" approach

<fantasai> Kevin: The spec will take until 2010 at least.

<fantasai> Kevin: So we have two(?) choices:

<fantasai> Kevin: We can go guerilla, and do this partly on our own.

<fantasai> Kevin: And slowly start to approach the TAG etc and later fold it into the official group

<fantasai> strike "choices" line

<fantasai> Karl: I will take an action item to make a proposal on the mailing list for the creation of a task force

<fantasai> Karl: Around HTML5 for Authors

<ChrisWilson> [break declared]

<fantasai> breaktime

<mauro> ACTION: Karl to make a proposal on the mailing list for the creation of a task force for developer community outreach [recorded in http://www.w3.org/2007/11/09-html-wg-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - Karl

trackbot-ng, status

trackbot-ng, reload

<trackbot-ng> Reloading Tracker config

<trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/

trackbot-ng, status

<scribe> ACTION: Karl to make a proposal on the mailing list for the creation of a task force for developer community outreach [recorded in http://www.w3.org/2007/11/09-html-wg-minutes.html#action02]

<trackbot-ng> Created ACTION-5 - Make a proposal on the mailing list for the creation of a task force for developer community outreach [on Karl Dubost - due 2007-11-16].

<myakura> if we do that in a wiki, it's great because it can be updated anytime by anybody

<myakura> however it's not that great because it'll be so hard catching up translating them...

HTML Working Group November f2f Day Two

Friday 09 Nov 2007

Attendees

Contents

story telling + testcases

HTML5 for authors

Summary of Action Items