See also: IRC log
CW reviews agenda...
ACTION: ChrisW discuss XHTML name coordination with XHTML 2 WG in the Hypertext CG [CONTINUES] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
CW: CG meets tomorrow; I saw recent mail from Dean [?] that looks like most of what I'll take there.
ACTION: DanC to discuss survey with Chris W and issue it, based on the most mature/agreed ones [DONE] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
ACTION: DanC to reserve a bridge for this alternating schedule [DONE] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
<oedipus> done: http://lists.w3.org/Archives/Public/public-html/2007Aug/0789.html
ACTION: Gregory to contact T.V. Raman about the Forms Task force [DONE] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
ACTION: DanC to set up an announcement mailing list, noodling with chaals [DONE] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
ACTION: MikeSmith to write up a summary of changes for last [period of time], description of where changes go [CONTINUES] [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
<Chris> survey results - http://www.w3.org/2002/09/wbs/40318/dprv/results
DanC: not sure the wiki issues list nor the list I'm maintaining is keeping up with demand... thinking about Sam's suggestion for a secretary
MikeSmith, you wanted to suggest we use an actual online bug-tracking system (e.g. bugzilla)
<Chris> is a bugtracker a good way to track issues?
<rubys> +1 on triage team concept
<DanC> (note that a bugzilla instance was set up ; it didn't get much traction. see http://esw.w3.org/topic/HTML/IssueTrackerRequirements for details.)
ChrisW: I don't mind using a bug system, though a triage team is important in any case and a list of one-line descriptions of bugs is important.
MikeSmith: we don't have to make it completely open for anybody to be able to raise a new issue in the tracker; a group of designated WG members could be given perms to raise new issues
chaals, you wanted to suggest trackbot cause it fits nicely with W3C tools and is simple and to
<DanC> (the TAG is starting to use trackbot/tracker; I don't love it, but Dom is handling RFEs at a satisfying rate.)
MikeSmith: using trackbot might be good ... definitely good dogfood case
<DanC> (for reference: http://www.w3.org/2001/tag/group/track/ )
<Chris> who should be the triage team?
Chaals volunteers
ACTION: ChrisW to start setting up a team to triage issues [recorded in http://www.w3.org/2007/08/30-html-wg-irc]
<mjs_> DanC: I am here but not on the phone but if you have questions I can answer here
<Chris> Ah, the stealth meeting multi-task. I salute you.
<Chris> survey results: http://www.w3.org/2002/09/wbs/40318/dprv/results
Chris: let's go through looking at what the disagreements are
Chris: Laura said "use the term 'user agent'"
not browser.
... I think we can accept that.
<Chris> Feedback 1: Laura Carlson, "don't use browser, use user agent". I think we can accept that.
CMN: can accept that - let's move on
Chris: Changing canvas example to a generic new element - think we should use something imaginary that will not be in the spec.
<Chris> Feedback 2: Laura Carlson, "change <canvas> to <newelement>". I'm inclined to do this.
<oedipus> +1 to generic "newelement"
PROPOSED RESOLUTION: We do not change 'browser' to user agent everywhere, the text is OK
Chris: Not sure it is a good idea that sites should require a specific user agent
CMN: Should be clear that you need some kind of fallback content that does the same job, not just says "you need a particular user agent"
Chris: Can you degrade gracefully enough that something will work on an older user agent?
CMN: These are principles, and the principle is pretty straightforward - it should work
Chris: for some reasonable value of "work"
PROPOSED RESOLUTION: We change 'canvas' to 'newelement
PROPOSED RESOLUTION: We overrule Scott Turner and accept the basic principle
Mike: The main problem we are trying to solve is interoperability of browsers. Other user agents are important so we should leave in at least the mention of the word browsers.
Mike: We should not be mandating to the editor that they don't say "browser" anywhere, although "user agent" should be mentioned too.
<Chris> Richard Ishida had comments on the list: http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
<oedipus> deserves an explicit mention -- blockquote deprecated for presentational purpose in HTML 4.01 to little effect
Richard Ishida suggests that the principle should be "degrade gracefully where possible - i.e. don't be beholden to every browser ever shipped"
Chris: Think that the fact this is a
principle not a law covers this. Deprecating support is IMHO a bad idea, but
deprecating practices is a good idea.
... I think the degrade gracefully section already says that effectively
<Chris> Design principles: http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD
CMN: Think that Richard's comment is covered by the text. "Should work reasonably well" is sufficiently flexible (and can be understood by the man on the Clapham Omnibus)
PROPOSED RESOLUTION: We think the principle meets Richard's request as written
<Chris> back to "supports existing content"...
<Chris> Laura Carlson: stipulate that current web sites shouldn't stop work in HTML5 UAs.
<Chris> *is not convinced this is necessarily possible.
Chris: First part - current sites shouldn't stop working. If you make it stronger than it is, we have a problem with things built for IE 6 and whether that has to work for HTML 5. The question is how strongly you take this principle - existing content already does browesr switching. if you make this too strong, then you create problems. IE has to have an HTML 5 mode and we hope not to kee doing that in the future, but current behaviour for old browsers is kind of goofy. I think this is already covered in the text. inclined not to do anything with the first part of the feedback.
CMN: Yeah, I am happy with the current wording in that respect
PROPOSED RESOLUTION: We do not strengthen the statement about sites working in HTML 5
Chris: agree that we should strike "We need to judge whether the value of the change is worth the cost."
CMN: Agree too. I wil come back to the "support existing content" in the context of accessibility. Accessbility is generally implemented much slower, so content that serves accessibility should be supported more strongly ...
<oedipus> +1 to chaals' observation
PROPOSED RESOLUTION: Strike the sentence "We need to judge whether the value of the change is worth the cost."
RATIONALE: It's a truism.
Laura: "Cross-browser content on the public Web should be given the most weight." should be changed to "Valid markup should be given the most weight, but legacy invalid markup shouldn't stop working."
<Chris> anyone else have thoughts about the valid markup comment from Laura?
Chris: I think valid markup should be given the most weight, but saying that legacy invalid markup shouldn't stop working takes a lot of the value out of that statement.
<mjs> I disagree that valid markup should be given more weight
<oedipus> should support valid markup that can validate against a DTD
<Chris> I think there's some value in encouraging well-written markup - e.g. wellformed - but I don't want to focus on ivory tower HTML4.01.
<oedipus> yes, mikeSmith - conformant is the word
CMN: I think it should be "well-written markup" that gets weight - a vague term meaning validity, working on lots of browsers, working on mobile, supporting accessibility, are the things that should have weight
<Zakim> MikeSmith, you wanted to say that we should give weight to valid markup, and probably not use "valid" at all (use "conformant" instead) for this case anyway
<Chris> mjs, what does "cross-browser" capture for you that "valid markup" doesn't?
<mjs> valid/conforming markup is a minority of web content and non-representative of the general web
<MikeSmith> even the term "well formed" is not appropriate here
<mjs> cross-browser means it works in multiple browsers today
<Chris> that's true. Would you give weight to overlapping <b> and <i> tags?
<mjs> in other words, content that only works in a single version of a single browser might be given less weight
CMN: [how many is multiple...? mjs, more browers is better as a rule for giving weight?]
<mjs> overlapping <b> and <i> should continue to be supported in a reasonably compatible way, yes, and I think the spec does that
Mike: Wellformed etc are relevant to XML, but not really HTML. Sticking to "conformant" makes more sense, but I agree with Maciej that it is not necessary to change this.
<Chris> I think "cross-browser" actually doesn't capture the majority of web content or is representative of the general web.
Chris: "works in IE6" probably would, though I'm not suggesting that as a replacement.
CMN:I think that accessibility is a reason to support markup that doesn't break in most browsers, even if it isn't strongly supported across browsers. which is sort of related to the "don't reinvent the wheel principle". Maybe that is strong enough to carry the point, if mentioned in the universal access principle
Chris: Maybe the right focus is to say "real-world, existing content on the current web should be given the most weight."
Chris: Validity is perhaps not the best target given today's web. "cross browser as representative of the real world web"
<mjs> chaals, obviously some of this is too fuzzy to quantify, but I think both the amount of content and how many browsers it works in is relevant
<oedipus> what about: "Browsers should retain residual markup designed for a specific purpose, such as accessibility or internationalization. Simply because new technologies and superior mechanisms have been identified, not all of them have been implemented. Moreover, disabled users are more likely to be users of "legacy technology" because it is the only technology that interacts correctly with third-party assistive technologies"
<mjs> chaals, also popularity of specific sites
<chaals> [mjs: amount and number of browsers makes sense to me. popularity of specific sites is mor difficult to measure... There are some hideously popular Indian sites with appalling markup...]
<mjs> Chris: if you factor in both quantity and popularity of content, I think "cross-browser" is a fairly good standard
Chris: Okay. I think we want wording, then, that captures "real-world, existing content on the web" and "cross-browser" standard.
<mjs> Chris, the basic idea is if there is some Firefox-only intranet site, we don't necessarily want to cater to every detail it depends on
<mjs> Chris, in part because we have no way to be aware of all such sites or know anything about what they depend on
Chris: I get that. But what about IE behavior on the public web, that a lot of public web content relies on.
CMN: So I am happy with "cross-browser real world content" given this is just a principle, and will make further suggestions in relation to other principles.
<mjs> If there is a large number of reasonably popular sites that depend critically on some IE-only feature, and currently fail in all other browsers, we should cater to that
Chris: I'd like to capture cross-browser (I do value that), and "real-world" as separate principles.
<oedipus> i don't understand what "cross-browser real world content" means
Chris: sorry, not principles - inputs to this principle.
<mjs> I agree
<chaals> [mjs not necessarily, since there is a lot of very popular korean content that depends on ActiveX and won't get supported whatever we say...]
Chris: "Real-world content, particularly that supported across browsers, should be given the most weight."?
<MikeSmith> ["sites that are known to work reliably across browsers"]
CMN: I Like Mike's wording
Chris: Mike - that captures x-browser, but not real-world. They're not necessarily the same set.
<oedipus> GJR: + and with third party assistive technologies or APIs
<mjs> chaals: support for ActiveX is out of scope for HTML I think
<MikeSmith> real-world = production sites that are not manufactured for testing but are intended to provide real information or real services to users
<oedipus> my plus was to mikesmith's "sites that are known to work reliably across browsers"
<mjs> Chris, I will take a shot at rephrasing it to indicate that multiple factors are relevant
CMN: When you have the two factors together, they are more important than they would be individually
<mjs> chaals, defining a cross-browser ActiveX ABI might aid interoperability but I don't think it is a task for this WG
<mjs> I would question whether there is a lot of popular content that only works when you have ActiveX, because we don't get a whole lot of bugs where that turns out to be the case but that seems like a side issue
Chris: OK. I suggested thinking of marquee as an example rather than activex.
<chaals> Propose: MJS come up with wording that clarifies the importance of cross browser, real world, working with accessibiltiy technologies, and the combination of these
<mjs> Safari supports marquee and I think Mozilla might as well
<oedipus> as long as there is user control to stop scrolling, and a means to obtain the contents of the stream, then , yeah, put in marquee
Chris: Mozilla didn't the last I checked. (Note that I use that as an example because I HATE that #$%*ing tag. :))
<billmason> The current FF 2.0 does support marquee.
Chris doesn't understand Karl's feedback
<chaals> Chris: You can't parse and not make something functional in HTML 5 ...
PROPOSED RESOLUTION: MJS come up with wording that clarifies the importance of cross browser, real world, works with accessibility technology, and the combination of these
ACTION: Chris follow up with Karl about his comment on "support existing content" [recorded in http://www.w3.org/2007/08/31-html-wg-minutes.html#action01]
Nik Thierry doesn't care about supporting old content.
Chris: Think this is a minority opinion
Philip Taylor thinks valid cross browser content should be given most weight, invalid content ignored.
<oedipus> nice sentiment, but would put most conent behind a firewall
CMN: I would like to support that, but given the web today I think it is unrealistic
Chris: There is invalid and invalid...I'd like for my legacy in 20-30 years to NOT be overlapping <b> and <i> tags... but the pragmatist in me doesn't know how to avoid that.
Chris: thing one and thing two?
<mjs_> Chris, I'm hoping HTML5 will make conformance checking a more appealing and therefore hopefully more widespread practice (by removing bogus reasons that content might fail checking and enabling it to find new kinds of problems like table integrity failures)
Chris: It would be nice to have two manuals for HTML 5. One for browser implementors to read, and one for everyone writing content to read. (Not really, but something to discourage poor practices that must still be supported)
CMN: That is the principle behind deprecating things in HTML 4, and there is such a concept in the draft already. maybe we can ask mjs to capture that more clearly?
Chris: Maciej, do you think HTML5 will discourage poor practices (even though they're still supported, as they must)?
<oedipus> worried about splintering of HTML5 along implementer/author lines
<mjs> chaals, one thing I'd like to do is add an introduction to the design principles is to make clear the distinction between the conforming language and the supported language
Chris: Don't worry, oedipus, I don't really mean it.
<mjs> chaals, because some of the principles apply only to one or the other, and it's kind of confusing as is
Chris: mjs, I like that idea.
<chaals> mjs, me too :)
Chris: I think it might need to extend to this principle, or be mentioned in it. (That "support" does not necessarily mean "condone".)
<mjs> Chris, I think if we can make conformance checking have a great benefit/cost ratio, and market it effectively as a good and beneficial practice, we might be able to reduce the incidence of poor authoring practices
CMN: maybe this is actually a principle in its own right: Authors shuld use good markup, but it is helpful to tell browsers how to support existing stuff even if it is bad.
<oedipus> it's unavoidable
<mjs> right now a lot of people violate HTML4 conformance in some trivial way because they think they have to, and then they just give up and throw out the baby with the bathwater
Chris: agreed. Not sure I see the way clear to that as well as you do right now, but I agree.
<oedipus> poor authoring
<oedipus> need as strong AU compliance as UA compliance!!!
<mjs> I agree it is unavoidable; I think we should both encourage more good authoring, and make sure we deal with not-as-great authoring as well as we can
Chris: exactly. Capture that. :)
PROPOSED RESOLUTION: We ask MJS to bring out more strongly in the draft that we need to encourage good authoring, and explain how to deal with not-so-good authoring... :)
Crhis: OK, that's all the time we have for today, folks. Dan will chair next week's telecon.
<oedipus> so the next telecon picks up on "Do Not Reinvent the Wheel" or reviews this telecon's proposed resolutions and completed action items?
Chris: picks up DNRtW. review of this telecon is in email.