"works in IE6" probably would, though I'm not suggesting that as a replacement.

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

Maybe the right focus is to say "real-world, existing content on the current web should be given the most weight."

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

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

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

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

I get that. But what about IE behavior on the public web, that a lot of public web content relies on.

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

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

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

"Real-world content, particularly that supported across browsers, should be given the most weight."?

<MikeSmith> ["sites that are known to work reliably across browsers"]

<chaals> CMN: Like Mike's wording

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

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

<mjs> but that seems like a side issue

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

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.

heh

I know the Emacs-w3 author... :)

doesn't understand Karl's feedback

<chaals> Chris: You can't parse and not make something functional in HTML 5 ...

oedipus - actually, he's been one of my best friends for the last dozen or so years...

<chaals> RESOLUTION: MJS come up with wording that clarifies the importance of cross browser, real world, works with accessibility technology, and the combination of these

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

<chaals> Nik Thierry doesn't acre about supporting old content.

<chaals> Chris: Think this is a minority opinion

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

<chaals> CMN: I would like to support that, but given the web today I think it is unrealistic

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

<MikeSmith> Philip` - what's your middle initial?

thing one and thing two? :) Sorry, my daughter's two and in to Dr. Suess...

that would be simpler, yes.

<MikeSmith> let's take a resolution on Philip`'s suggestion

<mjs_> Chris: I'm hoping HTML5 will make conformance checking a more appealing and therefore hopefully more widespread practice

<mjs> (by removing bogus reasons that content might fail checking and enabling it to find new kinds of problems like table integrity failures)

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

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

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

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

mjs - I like that idea.

<chaals> mjs, me too :)

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

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

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

exactly. Capture that. :)

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

the first two principles? :)

<mjs> I might have time to do some more feedback gathering and perhaps some editing later tonight

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?

OK.

picks up DNRtW. review of this telecon is in email.

<oedipus> ok

thanks all.

<chaals> ADJOURNED

<mjs> I'm hoping I can field some of the feedback in advance of the telecom progress through it, maybe that will help

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/accessible/working with accessibiltiy technologies/
No ScribeNick specified.  Guessing ScribeNick: Chris
Inferring Scribes: Chris

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Bob_le_Pointu CMN Chris DanC Dashiva GJR Gregory_Rosmaita Hixie Lachy Mike MikeSmith Philip Propose Thezilch Yudai aroben beowulf billmason billyjack bogi chaals deltab drry gavin_ gsnedders hendry hober jgraham jmb johnst karl krijnh laplink mjs mjs_ oedipus olivier robburns rubys sbuluf tH xover zcorpan_
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/08/31-html-wg-minutes.html
People with action items: chris

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