HTML Issue Tracking Teleconference -- 28 Aug 2008

<trackbot> Date: 28 August 2008

<anne> MikeSmith, I will make sure I make next week, I have to go now :/

<anne> Lachy, could you or zcorpan join to replace me?

<MikeSmith> anne: OK

<anne> Lachy, thanks in advance :)

<dsinger> thx oedipus

no problem dsinger

<dsinger> someone needs to mute their phone

<Josh> Thanks Mike

<Josh> yup

<dsinger> aaaaaah

<Josh> mae culpa

<Josh> No worries

<MikeSmith> ChrisWilson: yoohoo

<ChrisWilson> yeah, I'm joining now - had to kick someone out of my office.

<Josh> am in internet cafe with trad tunes in the background..

<MikeSmith> hsivonen: if you have time and interest in the headers discussion, would be happy to have you on the call

<Lachy> I'm here now, I suppose I can call in

<MikeSmith> Lachy: thanks

<scribe> scribe: Gregory_Rosmaita

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

<scribe> scribeNick: oedipus

<Laura> ACTION 72 and ISSUE 57 headers:

<trackbot> Sorry, couldn't find user - 72

<Laura> http://www.w3.org/html/wg/tracker/actions/72

<Laura> http://www.w3.org/html/wg/tracker/issues/57

<Laura> Action 72 Deliverable:

<trackbot> Sorry, couldn't find user - 72

<Laura> http://esw.w3.org/topic/HTML/Action72Headers

<Laura> Discussion on public-html for Deliverable for Action 72 @headers

<Laura> http://lists.w3.org/Archives/Public/public-html/2008Aug/thread.html#msg518

<ChrisWilson> reviewing issues from tracker?

<Laura> table headers - clear description of problem

<Laura> http://lists.w3.org/Archives/Public/public-html/2008Aug/thread.html#msg679

<Laura> Previous teleconf discussions:

<Laura> 17 July 2008 meeting (Rough IRC Teleconf minutes only):

ACTION 72 - Table Headers

<Laura> http://krijnhoetmer.nl/irc-logs/html-wg/20080717#l-394

<Laura> 7 July 2008 meeting:

<Laura> http://www.w3.org/2008/07/10-html-wg-minutes.html#item06

<Laura> Bug Report 5822:

<Laura> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822

<MikeSmith> action-72?

<trackbot> ACTION-72 -- Joshue O Connor to rewrite spec to reinstate id/headers AND their functionality by specifically stating that headers are allowed to reference a td. Reword the current definition of the headers attribute so that each of the space separated tokens must have the value of the ID value of a th or td element. -- due 2008-08-21 -- PENDINGREVIEW

<trackbot> http://www.w3.org/html/wg/tracker/actions/72

<Laura> Recent Testing:

<Laura> http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822

<Laura> Previous Testing:

<Laura> http://esw.w3.org/topic/HTML/TableAccessibility

<Laura> @headers Issue History:

<Laura> http://esw.w3.org/topic/HTML/IssueTableHeaders

<Laura> @headers has been an issue since May 2007 (Issue is over 15 months old):

<Laura> http://esw.w3.org/topic/HTML/IssueTableHeaders#head-bac4baeb0cd0ea09b7f76ff9c409740257566408

<Josh> Thanks Laura :-)

<ChrisWilson> okay, pausing for a moment.

CW: what needs to be reviewed?

LC: deliverable

<Josh> The deliverable is on the wiki http://esw.w3.org/topic/HTML/Action72Headers

<smedero> http://lists.w3.org/Archives/Public/public-html/2008Aug/0518.html

<Laura> http://esw.w3.org/topic/HTML/Action72Headers

<Josh> yup

SF: difference is that @headers be allowed on TD

LC: just add "or TD"

<ChrisWilson> yes

<ChrisWilson> sorry, I'm reading.

CW: discussion - pros cons - concerns about this as solution?

<Lachy> I'm not clear about what the proposal/issue is

<Laura> The current spec contains a feature that is not implemented by any assistve technology, so there is no method in HTML5 for marking up complex and irregular data tables accessibly. headers/id is well supported by AT and is used to ensure that accessibility of complex irregular data tables. If in the future a new feature becomes well supported by AT's, then remove headers/id feature from the spec. (It is a two word edit)

<Laura> Legacy and current AT's do not support the new HTML5 way of associating header cells and data cells. But they do support headers/id.

<Laura> We know AT implementers support headers/id:

<Laura> http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822

<Laura> http://esw.w3.org/topic/HTML/TableAccessibility

<Laura> http://esw.w3.org/topic/HTML/IssueTableHeaders#head-33a3d0ffbf5c6936b165f1ef92a80d98015073fb

<Laura> For AT backwards compatibility alone, Action 72 should be accepted and the definition of the headers attribute be extended to allow the headers attribute to reference a td.

<Lachy> were there example tables provided as evidence that require @headers to reference a TD?

<Laura> Complex and irregular tables cannot be marked up in HTML5 according to the cuurent draft. The current spec does not provide current and legacy AT with the required information about relationships between headers and data. So to support AT's that do not implement the HTML5 algorithms, authors who want to use HTML5 will be forced to write non-conformant code. headers/id needs to be grandfathered into the spec.

GL: concerned that the specification needs to be amended to include multiple references to TD - impossible to mark up an reasonably complex table - ATs already support it, and is lightweight solution, so i would ask it be put back in

<Zakim> oedipus, you wanted to say plus 1

<Josh> +1 to Gez

GJR: plus 1 to adding "to TD"

<ChrisWilson> Lachy, did you want to discuss the con side?

<Stevef> +1 to gez

<ChrisWilson> ok, type away.

<Lachy> can someone answer the above question I wrote? --> were there example tables provided as evidence that require @headers to reference a TD?

<Lachy> if so, where are they documented?

<DanC> (anybody have a summary of the arguments against? ah... I find "Why Headers Should Not be Included" part of http://esw.w3.org/topic/HTML/IssueTableHeaders )

<Laura> http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822

<Josh> There are Gez samples?

DC: confused about heirarchical TH

<Josh> Hierarchical headers are not allowed in HTML 5 ..

<Laura> As hierarchical headers are not allowed in HTML5, this means that conceptual headers (cells that contain data and have their own header, but act as a header for other cells in the table) must be marked up as a td. As these cells are conceptually headings, the headers attribute should be able to reference the id attribute of these cells.

<Josh> THanks Gez ..

GZ: if have TH can't have nested TH - will put example in IRC and talk WG through it

<Gez> http://juicystudio.com/wcag/tables/complexdatatable.html

<Josh> here tis http://juicystudio.com/wcag/tables/complexdatatable.html

<Josh> snap :-)

<MikeSmith> so this is a table with rowspans

<Lachy> I'd argue that those dates should be marked up as TH, because they are headers

<DanC> odd... <td> for 12/12/2005 and Budgeted

GZ: table which might be used by investment company - small table that demonstrates point of why headers necessary - for each datum, screen reader user needs to know values (has actual headers) - "running cost" is a pure header, but "partner portal" is not a TH, but should be a TD; all data need to be marked up as TD, but need @headers associations for assistive tech to work with such a simple table

<ChrisWilson> but what about budgeted, actual, etc - they can't be THs/

<Lachy> and they're even styled to look like headers, despite using <td> in the markup

<ChrisWilson> @DanC why odd?

<Lachy> so they should just use TH

lachy, style is irrelevant - separate content from presentation

<Laura> Regarding the idea of nested headers: The headers attribute can reference a th, so if the tds are changed to ths, the relationship would be complete. But that isn't allowed in the editor's draft, as nested headers aren't allowed. It also creates a new problem of what is the automatic scope association of a th in the middle of a table. Does it apply to the row (to the left?, to the right?, both directions?), does it apply to the column (above? below? both

DC: look like headers

CW: running dates headers, but not budgeted, actual, etc.

<Lachy> oedipus, I know. But the fact that, to a sighted user, they're made to look as if they are headers, then it means the author is trying to convey that they are headers

<Gez> They could have been styled on thead, but that's just how our client styled it

lachy, not really - they are just "important" to the author

<Josh> These relationships need semantic hooks that AT can use.. hence the suggestion.

MS: table header cell is exact language
... not defined in much detail beyond that

CW: could argue that anything that should be considered a header should be a TH?

<Lachy> yes

CW: forecasted in example would then be TH

DC: that would be my first guess

<Josh> tds will act as virtual headers - as such - if their ids can be referenced by headers.

<Josh> By *true* headers, as such.

GZ: if had more data in table, total cost of ownership etc. in extreme right column; if ended up with budgeted anual forcast as TH, would look like that is header for rest of row, which isn't correct; nested headers don't make such sent

CW: additional content to the right of running cost - essentially making running cost a nested table containing running cost over time, but can't carry table alignment across multiple partner portals

<Josh> At the very least this example shows a deficiency in the current spec that needs to be addressed,

<DanC> (while in this case, "Budgeted" looks like a <th> to me, it seems like there's an established state-of-the-art that uses <td>, and it works, and I don't see much reason to stop them.)

GZ: yes - if sighted easy, if using AT have to drill into table - massive disadvantage

<Josh> yes.

<ChrisWilson> yes, but we're not in person, so don't see a better way

<Zakim> MikeSmith, you wanted to ask about solution of restructuring the data into a different table and to suggest that one assessment of this particular table might be that it's simply

<Laura> Gez: Most of the examples of complex data tables that require headers/id associations have not been built by hand. They're usually built server-side, after analysts select the data they want to report on, and generating the relationships is easy for the software. When composite data is included, headers are usually required, as the composite data has a finite range that might not run for the remaining column/row. This can sometimes be overcome (if there a

<Josh> Quering and interogating data tables is a complex task for many users of AT.

MS: part of discussion and solutions that have been advanced for some cases - don't know if this table falls into that case - there are certain tables that are fundamentally badly designed - not fixing poor design by adding features for AT software - better solution is to redesign table
... do wonder about case of fixing via markup versus fixing data into more appropriate form; nested rowspans can be presented in other ways that don't rely on rowspans

DC: true

<Laura> "It may be true that it is possible to restructure many complex data tables by adding rowgroup or colgroup elements to the table and by altering the spans of cells in such a way that the scope attribute can specify the header cells for all data cells. I am not convinced but it is true for some of the "classic" examples. That process is complicated and cumbersome. It basically requires rewriting the table. Compare that with the headers/id approach. ANY Tab

<Laura> http://lists.w3.org/Archives/Public/public-html/2007Jun/0103.html

<ChrisWilson> s DC/CW

MS: not helping by enabling bad design

CW: suggesting re-design table model to take into account compound data scenarios

MS: right

<Josh> @MS: The mark up should facilitate how authors *will* mark up tables, though I agree that tables are often very badly designed.

<smedero> Gez, do you have an URL for an unmodified "complexdatatable" example available? (with the additional rows and such to the right of the "running cost")

CW: not sure if suggesting way solving problem in example - can understand why this set of data would be presented in this manner - is a compound data scenario - not representible today, so authors have to use hack; are you saying authors shouldn't do this or improve the table algorithm

<Josh> Note that headers/id association are rather well supported by much current AT so Gez's solution is rather simple and elegant.

MS: case-by-case stuff comes up and have to decide if real solution is restructuring the data
... don't know if would be right solution for majority of cases, but been discussed on list

<Josh> Will authors change the way that they mark up tables that much as we transition to HTML 5? Probably not.

<DanC> (Steve is making the point I was queued to make)

SF: understand MS' argument, but this table is an example of a table that came from a custormer - generated by database into multiple formats, all quite complex - shouldn't be in business of telling people how to order data, rather than providing binding so data can be presented in accordance with author's wishes/client's needs
... cannot markup tables in this way" proscription will be ignored

<Josh> +1 Steve and Dan.

<Josh> Real world cases will define how the language should behave to a degree..

SF: need to provide way to mark up so is accessible - people are doing this, and that isn't going to change

GZ: user-generated table - generated on options user has determined - user should be able to exert control over data - this is what people are asking for: information in the order that they want to see it - if marked up like this SR users will be disadvantaged

<DanC> (I'm not interested in using HTML conformance to enforce some idea of "good style". if the software out there groks @headers -> <td> and people are making use of it, seems OK to me. I don't see much reason to upset this applecart.)

<Josh> @GJR: Tables are presentational. They only have meaning by the semantic associations that are given to them. The user should be able to control the data to get what they need. User needs will vary. One size does not fit all.

<Laura> People who use screen readers listen to information, without any visual cues. They currently rely on the headers/id mechanism to be able to comprehend complex table data.

CW: enforcing an association with tables being presentational not understand

GJR: purely presentational

CW: want to steer away from TABLE as presentational and semantic
... semantic needs to be conveyed which is point of @header

<Josh> @Chris: Yes.

<dsinger> (sorry guys I have to drop off the phone...and step away from IRC...)

<ChrisWilson> Lachy, did you have any comments on the example?

<Lachy> no

<Josh> GJR: Tables are presentational. By definition of the X/Y relationships the explicit associations must be programatic..

<ChrisWilson> do you accept it as an interesting example?

GJR: no gestalt view, no semantic info from TABLE
... hence need for headers/id bindings

CW: SF was asking downside of taking this on

<Josh> Is there a down side to the proposal?

<jgraham> Hmm. looks like I might have had an opinion here

<Lachy> ChrisWilson, sure, it's interesting. I don't agree with the way it's all marked up, as pointed out before, but it still has some interesting issues

<Josh> +1 Chris

<Laura> +1

<ChrisWilson> is there any dissenting opinion?

CW: good example we've been discussion - should explicitly link-to in ACTION - makes enough sense to me to say we should extend definition of headers to included TDs - need demonstrated, no compelling counter agruments advanced

GJR: plus 1

<Julian> +1

CW: explicitly said would be discussed and polled here - if had strong opinion, expected people to show up or articulate position on list

<Josh> Good stuff.

CW: would like to close this
... with no formal objections to why this is a good idea, would like to close

<Lachy> all of this discussion needs to be summarised and posted to the mailing lists where I and others, can have more time to analyise it thoroughly

<jgraham> Can someone fill me on briefly on what the idea is

<DanC> Lachy, I'm pretty confident all the arguments made on the phone today are already in email

<Josh> @James: See http://esw.w3.org/topic/HTML/Action72Headers#head-14f006a74dc57f338be03afe43e7409e9828a86f

CW: no one yet objected with good arguement; in lack of counter argument, feel this should be considered right solution

LC: thanks

<Lachy> DanC, good. But I still don't think that making a binding decision like this on a telcon is the right approach

<MikeSmith> jgraham: idea is that there are cases where @headers seems to be needed on th

<MikeSmith> not just on td

<Josh> thats it.

<Gez> It's the opposite of what Mike Smith just said

<Lachy> wait, I thought it was just about having headers reference a TD, not that it should also be usable on TH?

ACTION ITEM REVIEW

<DanC> Lachy, I suppose the decision isn't binding until it's been put to the WG

<jgraham> Oh, I have already explained why I think that is a bad approach in general

CW: MikeSmith, you have 2 due

<Josh> sorry, long day..

<MikeSmith> jgraham: http://juicystudio.com/wcag/tables/complexdatatable.html is the example under discussion

CW: reviewed agenda tracker, disposed of first item

<jgraham> MikeSmith: For that particular example it is not needed as far as I can tell

Issue 57 not a Duplicate of Issue 20

<ChrisWilson> item 3 - discuss why issue-57 is not a dupe of issue-20

<MikeSmith> to jgraham - Stevef and Gez have pointed out that table is an actual table from one of their customers

<jgraham> (although my alternative proposal is also a modification of the current spec)

JOC: discussion we just had was sufficient to explain difference - lot of discussion same as table issue - markup versus design; bit of non-issue for me, really

SF: process point: discussed and said "right thing to do" - how will progress?

<Josh> @james: Rationale for Changing the Spec

<Josh> * The constraint that the headers attribute can only reference the id attribute value of a header cell is of very little use, and makes it impossible to define most complex data tables accessibly.

<Josh> * A mechanism to associate data cells with conceptual header cells and pure headings is required to determine content relationships.

<Josh> *

<Josh> For further rationale and history of this issue consult the reference section below.

<Josh> HTH

CW: took action item assigned to josh and will figure out how to ensure edit gets made in timely fashion

SF: thank you

CW: missing alt issue (31)?

briefly discuss missing-alt issue-31

Issue 31 - Missing @alt issue

<DanC> action-54?

<trackbot> ACTION-54 -- Chris Wilson to ask PF WG to look at drafted text for HTML 5 spec to require producers/authors to include @alt on img elements -- due 2008-08-29 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/54

<Laura> ACTION: 54 to First Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action01]

<trackbot> Sorry, couldn't find user - 54

<Laura> http://esw.w3.org/topic/HTML/Action54AltAttribute

<Laura> ACTION: 54 to Second Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action02]

<trackbot> Sorry, couldn't find user - 54

<Laura> http://esw.w3.org/topic/HTML/Action54AltAttributeSecondDraft

<Laura> ACTION: 54 to Third Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action03]

<trackbot> Sorry, couldn't find user - 54

<Laura> http://esw.w3.org/topic/HTML/Action54AltAttributeThirdDraft

DC: action 54 - chris collecting info from PF WG - latest from AlG chair of PF is not done yet - ETA?

CW: that is on my list of things to discuss with Al

<Laura> The Third Draft takes a minimalist apporach because the cuurent editor's draft includes guidance on how authors should include text alternatives for images, and some of the guidance is incorrect; such as suggesting that it's not always reasonable to provide alt text, which will become open to abuse. That guidance needs to be removed from the HTML5 specification, and the specification should instead point authors to WCAG, authoring tools to ATAG, and user

DC: input pending from PF still; other piece of state-of-art is ...

<DanC> recent summary from the editor http://lists.w3.org/Archives/Public/public-html/2008Aug/0759.html

<Laura> The second draft version is still waiting for a reply from the PFWG regarding our March and April requests:

<Laura> http://lists.w3.org/Archives/Public/public-html/2008Apr/0408.html

<Laura> http://lists.w3.org/Archives/Public/public-html/2008Mar/0234.html

<Laura> I emailed Al for an update a while ago:

<Laura> http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0024.html

<DanC> and new proposal

<jgraham> Josh: did you see my laternative proposal? I think it's much easier for authors in that case and, given a choice between the two (they are not mutually exclusive) a better win for accessibility on the whole web

<Josh> @James: No, will have a look. Have you a ref?

DC: 15 or so options

<DanC> [[

<DanC> F. We could say that for these "key content without alt text" cases, we

<DanC> have the alt="" attribute omitted, but there must be at least one of the

<DanC> above, and the first of the above that is present must include sufficient

<DanC> information to orient the user.

<DanC> ]]

<Laura> We still need their input on all three drafts.

<DanC> [[

<DanC> Are there cases where the image is lacking good alt text that wouldn't be

<DanC> covered by one of the following?:

<DanC> - title="" attribute on the <img> itself

<DanC> - <legend> of the <figure> that contains the <img>

<DanC> - heading of the section that contains the <img>

<DanC> F. We could say that for these "key content without alt text" cases, we

<DanC> have the alt="" attribute omitted, but there must be at least one of the

<DanC> above, and the first of the above that is present must include sufficient

<Laura> Karl's proposal:

<Laura> "All img elements must have the alt content attribute set. The accessibility requirements on the possible values of the alt attributes are defined by WCAG 2.0 and not HTML 5."

<Laura> http://lists.w3.org/Archives/Public/public-html/2008Aug/0437.html

<DanC> information to orient the user.

<DanC> ]]

<jgraham> Josh: I'm just looking

CW: anything to discuss on call, DanC?

DC: no, but others have input

<smedero> There was also T.V. Raman's proposal (based on Ian's proposal "F"): http://lists.w3.org/Archives/Public/public-html/2008Aug/att-0829/image-alt.html

<Josh> @James: Why not add your idea to the tracker?

SF: this action has been open for a while, but the spec has changed significantly a number of times since issue officially opened - this last one just last week -- PF has to re-evaluate every time a change occurs - PF is now dedicating weekly telecons to HTML5 issues so should expedite feedback from PF to HTML WG

<Josh> @Steve: Yes.

<Zakim> MikeSmith, you wanted to just note that the alt="{photo}" stuff is gone now

<ChrisWilson> unmute Gregory_Rosmaita

GJR: working on @role for media specific and all objects
... legend maps to @alt; desc to @longdesc - http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute

http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements

<jgraham> Josh: It's roughly explained in http://lists.w3.org/Archives/Public/public-html/2008Aug/0561.html and the sample implementation is http://tinyurl.com/624mko (it's not clear what markup changes I made there)

DC: TV Raman's input - make @alt optional - @role for graphical elements

<Josh> @thanks James.. Do add to tracker.

GJR: please consult the 2 esw wiki pages above - my phone is somewhere on the floor
... flickr case is server-side tool problem, not spec problem

CW: confused - camera do provide metadata, but of limited/no use

LC: date data could be useful

DC: allows you to tell photo from screen shot

<Lachy> I already posted my comments about the EXIF metadata issue to the list. TV Ramen failed to provide any use cases, or explain why a DOM API is useful at all, as opposed to a a UA specific UI for accessing it

CW: not really - allows you to tell picture taken from digital camera, but not screen shot which could be output of a digital device
... if access data is there, may be useful and interesting - it not being there, though is the common case and lack of it doesn't tell anyone anything
... like to discuss more - pretty lively discussion - would be glad to hold over for another week
... any other comments?

[no comments]

<ChrisWilson> topic issue-54

ISSUE 54

CW: MikeS had action

MS: talked with julian about it last week; julian argued that cases henri brought up were edge cases; other issues around why can't produce HTML5 conformant output with current XSLT schemas

<Lachy> Those are problems that need to be addressed in the XSLT specification, not the HTML5 spec

MS: ready to bring proposal to group: optional public identifier on DOCTYPE - julian posted to list on overlapping issue - don't know the events associated with empty elements in HTML5 - in text/html not going to produce empty elements; wanted to ask julian if wants to go ahead with idea of adding public id to doctype as optional part of doctype

JR: should do - discussion on how to produce empty element should be discussed - concerned that more pieces of code in world than XSLT engines that make decisions about empty elements that cannot be represented as start text with end text
... should be discussed as 2 issues

<Lachy> No, it is not a good idea to place constraints on the development of HTML based on the flaws of other tools/langauges

MS: will go forward with them as 2 separate issue

JR: ok

discuss issue-55

<ChrisWilson> (head-profile issue)

@profile for HEAD (Issue 55)

DC: question hasn't been put, so not much to discuss

<Julian> Lachy, the flaw is in HTML (requiring out of band knowledge about the format)

CW: dependent upon an action item?

<DanC> action-75?

<trackbot> ACTION-75 -- Michael(tm) Smith to raise question to group about Yes, leave @profile out, No, re-add it -- and cite Hixie's summary of the discussion -- due 2008-08-28 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/75

<ChrisWilson> any other items for discussion?

[fyi] plus 1 to leave @profile IN

CW: move to adjourn

<ChrisWilson> move to adjourn?

DC: seconded

<Julian> bye

<Lachy> Julian, no, I disagree

<Lachy> bye

<ChrisWilson> thanks all.

<Josh> Bye

ADJOURNED

<Stevef> see ya!

<ChrisWilson> heh

<MikeSmith> oedipus: thatnks

<ChrisWilson> Thanks for scribing, Gregory.

<ChrisWilson> 1

<Laura> bye

no problem guys - good meeting

<ChrisWilson> umm, I don't think I saw any, no.

<ChrisWilson> (heh. yeah, we aren't going THERE.)

lol

<ChrisWilson> 1

<scribe> ACTION: [NEW] 54 to First Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action01]

<scribe> ACTION: [NEW] 54 to Second Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action02]

<scribe> ACTION: [NEW] 54 to Third Draft [recorded in http://www.w3.org/2008/08/28-html-wg-minutes.html#action03]

<ChrisWilson> go for it

ok, will do

- DRAFT -

HTML Issue Tracking Teleconference

28 Aug 2008

Attendees

Contents

ACTION 72 - Table Headers

ACTION ITEM REVIEW

Issue 57 not a Duplicate of Issue 20

briefly discuss missing-alt issue-31

Issue 31 - Missing @alt issue

ISSUE 54

discuss issue-55

@profile for HEAD (Issue 55)

Summary of Action Items

Scribe.perl diagnostic output