- From: Michael(tm) Smith <mike@w3.org>
- Date: Mon, 3 Sep 2007 16:00:40 +0900
- To: public-html@w3.org
- Message-ID: <20070903070036.GE6674@mikesmith>
http://www.w3.org/2007/08/30-html-wg-minutes.html
Agenda
http://lists.w3.org/Archives/Public/public-html/2007Aug/1128.html
Present
DanC, Chaals, ChrisW, MikeSmith, Sam Ruby, Gregory Rosmaita,
Maciej Stachowiak (IRC only)
Regrets
Chair
Chris Wilson
Scribe
chaals
Contents
* Topics
1. Convene, review agenda, actions
2. issue tracking
3. Design Principles
4. degrade gracefully.
5. Support existing content
* Summary of Action Items
_________________________________________________________
Convene, review agenda, actions
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]
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]
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]
http://www.w3.org/2007/08/30-html-wg-irc
<oedipus> done:
http://lists.w3.org/Archives/Public/public-html/2007Aug/0789.htm
l
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]
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]
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]
http://www.w3.org/2007/08/30-html-wg-irc
issue tracking
<Chris> survey results -
http://www.w3.org/2002/09/wbs/40318/dprv/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.)
http://esw.w3.org/topic/HTML/IssueTrackerRequirements
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/ )
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]
http://www.w3.org/2007/08/30-html-wg-irc
Design Principles
<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
http://www.w3.org/2002/09/wbs/40318/dprv/results
Chris: let's go through looking at what the disagreements are
degrade gracefully.
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.htm
l
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
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"...
Support 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]
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.
Summary of Action Items
* [NEW] ACTION: ChrisW to start setting up a team to triage issues
recorded in http://www.w3.org/2007/08/30-html-wg-irc]
* [NEW] 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]
* [PENDING] ACTION: ChrisW discuss XHTML name coordination with
XHTML 2 WG in the Hypertext CG [recorded in
http://www.w3.org/2007/08/30-html-wg-irc]
* [PENDING] ACTION: MikeSmith to write up a summary of changes for
last [period of time], description of where changes go [recorded
in http://www.w3.org/2007/08/30-html-wg-irc]
* [DONE] ACTION: DanC to discuss survey with Chris W and issue it,
based on the most mature/agreed ones [recorded in
http://www.w3.org/2007/08/30-html-wg-irc]
* [DONE] ACTION: DanC to reserve a bridge for this alternating
schedule [recorded in
http://www.w3.org/2007/08/30-html-wg-irc]
* [DONE] ACTION: DanC to set up an announcement mailing list,
noodling with chaals [recorded in
http://www.w3.org/2007/08/30-html-wg-irc]
* [DONE] ACTION: Gregory to contact T.V. Raman about the Forms
Task force [recorded in
http://www.w3.org/2007/08/30-html-wg-irc]
_________________________________________________________
--
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/
Received on Monday, 3 September 2007 07:01:09 UTC