HTML WG f2f -- 02 Nov 2012

<gitbot> [13html] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/a66eb4f72165eb6101f9c7f09f3deccfa6133c18

<gitbot> 13html/06feature/whatwg 14a66eb4f 15ianh: [ac] (3) Define a syntax for comments in WebVTT (doesn't affect parsers)...

<gitbot> [13html] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/3c4747eae0785de87cc4626d37ab2526b81724e3

<gitbot> 13html/06feature/whatwg 143c4747e 15ianh: [e] (0) Fix some typos or copypasta....

<MikeSmith> title: HTML WG f2f

<MikeSmith> scribe: MikeSmith

MultilingualWeb-LT

Paul reviews the agenda http://www.w3.org/html/wg/wiki/TPAC2012

plan is to discuss MultilingualWeb-LT, i18n bugs in the morning

<fsasaki> http://www.w3.org/International/multilingualweb/lt/wiki/File:Its20-html5-tpac2012.pdf

paulc: we have some friends here from the MultilingualWeb-LT WG

fsasaki steps up to the mic

MLW-LT WG members stand up -- 10+ people here

fsasaki on slide 2 of his presentation

slide 3 shows example documents

<Jirka> More examples are in editor's draft at http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html

fsasaki: "translate" is now a native HTML attribute

slide 4 shows more examples

fsasaki: this shows one of the hyphenated its attributes

slide 5 has some links

fsasaki: Frederick will show some demos
... we want to go to LC in November

… and have validator support when we go to LC

… we want feedback on this section "How to use ITS metadata in HTML" by end of November

… I wanted to make you aware of that plan

Fredrik at the decks now

<fsasaki> speaker is frederik linden from enlaso

Frederik describing use cases

describing filters design, processing through "ITS engine"

<fsasaki> frederiks slides are at http://www.w3.org/International/multilingualweb/lt/wiki/File:Some_Use_Cases_with_the_Current_Okapi_Framework_Implementation_of_ITS_2.0%28Yves_Savourel-2012-09-25%29.pptx

now describing "Translation Package Creation" slide

<fsasaki> (sorry, currently ppt only, pdf will come later)

describing benefits

<fsasaki> here slides in pdf http://www.w3.org/International/multilingualweb/lt/wiki/File:Some_Use_Cases_with_the_Current_Okapi_Framework_Implementation_of_ITS_2.0%28Yves_Savourel-2012-09-25%29.pdf

we enter the demonstration

showing "Rainbow" implementation

fsasaki: there are other use cases described in our document but we just wanted to show you this one demo for now

… main thing we want is your feedback

paulc: let's go around the room and see if anybody has any questions
... fsasaki you pointed us at your document

<fsasaki> http://www.w3.org/International/multilingualweb/lt/wiki/File:Its20-html5-tpac2012.pdf

paulc: fsasaki are there any particular parts that you yourself are concerned about? that you may or may not have got right?
... the group is large and so it's been difficult to get consensus for comments on other group's specs

… so it's more likely that you'll get individual comments

<paulc> http://www.w3.org/TR/its20/#html5-markup

mjs: these ITS extensions to HTML, are they intended to be in actual HTML content that is published over the Web?

… or are they intended for internal use?

Jirka: content published over the Web?

mjs: so 3rd-party tools will consume this?

Jirka: yeah

cameronjones: is this something that's going to be integrated with HTML itself?

Jirka: similar to say, style attribute in HTML. Can use CSS selectors or XPath

cameronjones: what's the default?

Jirka: XPath
... default is to apply to complete subtree

fsasaki: about CSS selectors, we would like to have that support

cjones: translation can be quite verbose, anything that can reduce that would be great

<fsasaki> fsasaki: but it is a feature at risk, so if you are interestd i that, please contact us for aslo implementations - thanks

… looks like it will help to reduce that verbosity

<darobin> - new dir values

<darobin> - concerns with ruby

<darobin> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=15278 Adding Islamic calendar support in HTML5

paulc thanks the MLW-LT WG for joining us this morning

<darobin> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=16965 i18n-ISSUE-97: Allowing a page to request a given locale (4.10.7.2 normativity)

the W3C Nu validator and validator.nu now already have support for ITS attributes, btw

i18n bugs

darobin gives an overview

<cjones> preent +cjones

r12a: want to set the scene first

… I will take about bi-directional text aka BIDI

r12a: imagine you have a data feed that provides info about restaurants

… including the name of the restaurant and some stars to show a rating

r12a: there are cases where you need to isolate a word from the surrounding text
... the isolation issue is really important when you don't know the directionality of the surrounding text but it's *also* important even when you do know
... the Unicode Consortium is going to introduce some new character codes to address this

… and the CSS specifications are going to be updated to address this

… and the Unicode Consortium is going to be saying that isolation should be use by default

r12a: there are some limitations with current solutions the authors have been using
... so we arrive at the bdi element

… it creates problems for templating and other things, because it splits information across two elements where not necessary

r12a: so it would be much simpler if we could just use the dir attribute

… with new values

… say "rli" and "lri"

r12a: we are not asking for the bdi element to be replaced

… because the bdi element still has some other use cases

r12a: what we're proposing would make it easier for authors

hsivonen: so considering adding values to the dir attribute, wouldn't that make the new values fall back to left-to-right in older attributes?

… what about adding a new attribute instead?

r12a: we want people to stop using ltr and rtl actually

… we realize there will be a bit of a difficult transition peried

… but authors can address that by using some CSS to address older browsers vs newer browsers

hsivonen: yeah, makes sense

mjs: if you want to deprecate use of the old values and have a combined thing, you can introduce a new attribute, say "isolation" (though maybe a shorter name)

… it's usually not a good idea to require people to jump through huge hoops to deal with fallback

mjs: I would strongly suggest that you consider a design for this that has good fallback

fantasai: the implementation in Mozilla for this would be one line of code, probably

r12a: people will need CSS anyway for bidi support
... we want people to take this up, and use of the dir attribute makes that easier
... about adding a new attribute, we would really like to get this in HTML5

hsivonen: I think the desire to get this into HTML5 is a terrible reason [for not using the best technical solution]

mjs: this would be considered a new feature whether you do it as a new attribute or new values on an existing attribute

<plh> mjs made my point

… as far as our CR exit criteria

<Zakim> MikeSmith, you wanted to say adding new values to existing attributes should be considered the same as adding new attributes

MikeSmith: mjs made my point too

r12a: what I am hearing is that we should develop an extension and that we should consider doing it some way other than adding new values to the dir attribute

cjones: deprecating ltr and rtl? good idea to do?

r12a: not sure yet

<paulc> - concerns with ruby

<paulc> Next item is - concerns with ruby

darobin: will require a few years time

Concerns with ruby markup

fantasai: ruby markup is used with Chinese and Japanese content, to annotate the characters with their pronunciations
... there is "mono ruby" and "group ruby" and from a markup perspective, those are the same
... we also have "jukugo ruby" which looks the same basically but is different for line breaking

… you have to know what the grouping is

… so that you don't break them in the wrong place (among other things)

fantasai: that XHTML WG came up with a bunch of elements

… the HTML WG came up with a simpler solution

fantasai: but aside from the number elements, the model for the two approaches are quite different

… it is a "column-based model" vs a "row-based model"

fantasai: is you are displaying the ruby text inline -- which has some use cases such as, say, display on a mobile phone

… Stuff like that is very easy if you have a row-based model

fantasai: that is a fallback issue, and important
... another case is double-sided ruby

… where you have annotations both above the character and below the character

fantasai: with HTML5 ruby markup you can deal with this by using two rt elements
... there are cases of double-sided ruby that you can't address just with multiple rt elements

… So the solution proposed for that has been to use "nested ruby"

… But there are problems with that

… One problem is that it amounts to having two different models

… And it requires different styling for nested ruby vs normal ruby

fantasai: so an additional thing that has not been considered is that there are cases where you have the possibility of running out of room for the annotations

… so that the annotations would end up overlapping

… these are things that have to be handled at the style layer

… so it's not a bunch of discrete boxes that don't know anything each other

… you ideally need to know "what's in this box next to me"

fantasai: I think the solution to all these problems is to go to a wholly row-based approach

… which is the same approach that's used for XHTML ruby

<inserted> fantasai: You can have a create a model that is compatible with both the HTML5 simple ruby as well as a row-based approach for the other cases

fantasai: so you need an rb element
... plus an rtc element

… which addresses the spanning use case

… which current model cannot be used for

r12a: is can actually

paulc: status of the related bugs?

fantasai: Hixie hijacked the bug we had which was just about parsing and [tried to made it into be about something else]

<hober> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13113 ( and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17967 )

hsivonen: I have three points -- two of my own and one channeling Hixie
... first, is there actual statistics on how often a Japanese print reader encounter these various types of ruby? Daily? Once a week? Yearly?

fantasai: depends on which case you mean?
... jukugo ruby is quite common

hsivonen: what does common mean in this case?
... again, daily? weekly?

fantasai: Koji can answer that

koji: I don't have exact numbers

r12a: the jukugo ruby thing is not an issue -- you can achieve it by styling
... the thing I think you were asking about more is double-sided ruby

hsivonen: I was asking about all of them

… that you can prioritize their importance

r12a: I have had people come up to me from Amazon and others and tell me that they need double-sided ruby support

hsivonen: question two, was the case about fallback for legacy UAs, or responsive design, or for the principle of semantics

<paulc> Note we still have 2 more items to discuss in this session:

<paulc> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=15278 Adding Islamic calendar support in HTML5

… Leading me to ask, in the case where you'd want it rendered inline with parenthesis, why don't you just mark it up with parenthesis?

<paulc> 2nd item is:

<paulc> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=16965 i18n-ISSUE-97: Allowing a page to request a given locale (4.10.7.2 normativity)

fantasai: all three are valid points. Fallback is not just for legacy UAs, but also newer layout engines for which ruby is not a high priority -- at least they can render something sensible. Reponsive design, but also to have markup independent of styling--the author has the choice to decide on a different rendering without going back and changing the markup.

darobin: like the case where you want to make the case more compact

hsivonen: OK, last, I think Hixie's argument was about frequency of use

… and about implementor indifference. [The implementors should be focusing on implementing simple ruby before they implement complex ruby.]

<inserted> fantasai: I'm not suggesting we have a model that does everything now

fantasai: question is, why aren't we going with the model that enables extension more easily?

<r12a> http://www.w3.org/TR/ruby-use-cases/

r12a: the i18n WG did not yet get a lot of traction saying that we should be doing things differently

… Hixie has added double-sided support

darobin: we could the same thing that we are doing for other features

… we could flag the current model as "at risk" and publish an extension spec

paulc: is the double-sided support that Hixie came up with already in our CR draft?

<fantasai> http://fantasai.inkedblade.net/weblog/2011/ruby/

darobin: yes

hsivonen: would the potential extension spec require a delta spec of the parser algorithm?

(discussion)

hsivonen: so the answer seems to be that it's unknown at this time
... I am generally unhappy about the idea of multiple delta specs to the parser algorithm

… especially since we currently have the parsing algorithm implemented in all major browser engines

i18n bugs

cjones: these two bugs are about the same thing

… Localization for this case is currently applied as a user setting

cjones: user's preferred locale is what always ends up being used

<fantasai> I agree with hsivonen's sentiment on the parser and would rather see the parser modified to not break potential extensions to ruby, and let the discussion on exactly how ruby is extended be independent of the parser

… this is a problem for multi-language documents. It provides no flexibility.

cjones: this should be seen as a form of translation rather than localization

… so maybe this could be controlled through the translate attribute

… [translate attribute] is something for document consumers and not so much for user agents

Norbert: sometimes a page loads other components that are not in the same language

… So start from the element that you want to format, and check to see if it has inherited a language, and if not, then go back up to the user preference

cjones: the reason browsers have taken the approach they have is that typically users want to see something in their own language

… so they are in effect overriding the author preferences with the user preferences

… but the problem with that is we provide no way to break out of that

hsivonen: browsers don't do right now what is already in the spec
... the spec already says what you want
... we can't fix this by having the spec say, "UAs must must must must do this"
... and adding new syntax is not going to make it any better
... it is completely unhelpful to munge pieces of a page into the language of the reader
... this is an artifact of the browser just trying to do one thing for the whole page vs trying to be helpful
... and issue of having the browser ship with support for all possible languages [that some piece of a page might be in]

r12a: I am wondering about whether the lang attribute is the right thing to use for locale
... Cameron, what do you want to have done with these bugs? Why are we discussing them here today?

cjones: there are always some dates that are pre-formatted by the server

… the problem already exists

hsivonen: the problem exists in implementations, it does not exist in the current spec text

Norbert: I don't agree that the problem does not exist in the spec

<Norbert> http://www.w3.org/TR/html5/states-of-the-type-attribute.html#input-impl-notes

… some of the relevant text is non-normative

hsivonen: so we can keep it non-normative for CR but make it normative after
... I think it would make sense to make it normative, after CR,

<paulc> Still pending - - https://www.w3.org/Bugs/Public/show_bug.cgi?id=15278 Adding Islamic calendar support in HTML5

darobin: It seems like a resolution for this is to agree to make it normative after CR

r12a: come talk to me about bug 15278 later

darobin: a decent number of the remaining i18n bugs are editorial

paulc: so r12a please work with darobin and the editors to deal with these bugs

<darobin> ACTION: Robin to summarise I18N discussion and bugs, copy public-i18n [recorded in http://www.w3.org/2012/11/02-html-wg-minutes.html#action01]

<trackbot> Sorry, couldn't find Robin. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<darobin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16959

Norbert: is there any chance of renaming the "global time" and "local time" in the spec

<hober> i18n-ISSUE-88

paulc: get together over coffee for that discussion

<scribe> ACTION: Robin to summarise I18N discussion and bugs, copy public-i18n [recorded in http://www.w3.org/2012/11/02-html-wg-minutes.html#action02]

<trackbot> Sorry, couldn't find Robin. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<scribe> ACTION: darobin to summarise I18N discussion and bugs, copy public-i18n [recorded in http://www.w3.org/2012/11/02-html-wg-minutes.html#action03]

<trackbot> Sorry, couldn't find darobin. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

trackbot, status

trackbot, reload

trackbot, bye

<scribe> ACTION: darobin to summarise I18N discussion and bugs, copy public-i18n [recorded in http://www.w3.org/2012/11/02-html-wg-minutes.html#action04]

<trackbot> Created ACTION-224 - Summarise I18N discussion and bugs, copy public-i18n [on Robin Berjon - due 2012-11-09].

<matt> scribe: Matt

Preparing for CR and WG Status

paulc: We'll review objections, features at risk, CR exit criteria, status of CR drafts, and HTML 5.1 planning.
... We'll reserve some time at the end for email organization discussion.
... We noticed during responsive images discussion that we didn't have a place for the discussion.

<paulc> http://www.w3.org/News/2012#entry-9619

paulc: Let's review the list of the recently published drafts

-> http://www.w3.org/News/2012#entry-9615 Recent Drafts

paulc: Coming out of this meeting I'd like to at least get a sentiment out of the people in this room about how we'll progress each of these docs.
... We'll go back to that list and get agreement on how we're progressing those documents.

<paulc> http://lists.w3.org/Archives/Public/public-html/2012Oct/0026.html

paulc: This email is what you agreed to do in the past from a CfC point of view.
... There was an explicit list of things you weren't agreeing to in that CfC too.
... You were agreeing to go to CR, but weren't explicitly agreeing to the exact terms of that.
... We still need to do the CR transition request, need to request FPWD of 5.1, FPWD of extension specs, and any other transitions for any other specs.
... There were two other items: accessibility TF statement (which we won't touch on), and agreement on full list of features at risk.
... Given that summary, which drafts are being proposed to go to CR?
... I believe we'll go to CR on four or five documents.
... The HTML 5 Core, Canvas 2D, Microdata, Polyglot and Alt-Techniques documents.
... We need to ask ourselves about the other drafts as well.
... Robin has said three docs would be prepared.

<paulc> 3 cr drafts: http://htmlwg.org/cr/

darobin: Those are generated from the same source document, the others I'd have to sync up with the other editors. We'll have a short meeting with Steve about that today. Elliott wasn't here and I have to have a conversation with him about how he generates it in order to get it.

paulc: So those five, does anyone disagree that they go to CR? The 2 docs don't have features at risk.

hsivonen: Lachy formally objected to making polyglot normative and I second that objection.

<paulc> FOs: http://dev.w3.org/html5/status/formal-objection-status.html

paulc: The Director asked us to confirm which of the FOs are still pertinent. I may have the number incorrect -- I seem to remember 11 at the time, but might have been higher -- it's now down to 5.
... There are two examples of the case just mentioned by hsivonen, Lachlan's objection to the polyglot document being on the Rec track and obviously if that FO was upheld it'd hardly make sense to take that document into CR.
... Then there's 2 objections to text alternatives.
... These were from May of last year and the 2nd objection fell out of sync with what we now do with extension specs.

<mjs> Lachy, it would be useful

paulc: These five were sent to the Director. We sent mail to him last week and let him know we'd done what he asked and pruned the list as much as possible. These five were confirmed as the objector wanted to maintain them. They'll be dealt with by the Director when we go to CR.
... We'll go to the Director with these docs and these five FOs and we'll come out with 5 or less docs.

mjs: After Lachlan made his formal objection to those docs being Rec track (rather than note), we made up a process that doesn't involve the whole change proposal dance for getting WG decision on what should be normative or not.
... The WG hasn't made a decision on these, the editors chose them being Rec track. No one chose to use that process, and it's unclear if it was because they didn't know the process or wanted FO.

hsivonen: I was unaware of the process.

mjs: It's not too late to do it now. Normativity of the document is a sort-of substantial change. If people didn't know about the process, we could do it now. The process is basically write a tracker issue and then have a preference poll.

<MikeSmith> trackbot: reload

mjs: I'd rather have a WG decision than throwing it in to the Director's corner.

<MikeSmith> trackbot, reload

glenn: I was wondering if anyone supports those being Rec track rather than notes.

<mjs> hsivonen, Lachy: process is here: http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#note-vs-rec

Steve: Yes. The doc I edit on alt techniques is normative because the corresponding advice in the HTML 5 spec is normative.

Stevef: The reason I developed the document is because the HTML 5 spec wouldn't change.

glenn: If the HTML 5 spec changed to use non-normative prose would that change your spec?

Stevef: No.

<mjs> hsivonen, Lachy: I believe that bugs already exist regarding normatively of both of these specs

paulc: Does anyone want the HTML/XHTML to be normative? The Director asked this to be produce that document.
... It'd be ironic if the Director has to be the one to deal with the FO.
... If we ask him if it's normative, I have a feeling we know the answer.

<MikeSmith> yes please can we get agreement to change the formal title of that document to Polygot

Cameron: Programmatically vs hand authoring, XHTML is easier to author in an algorithmic fashion and it's still good to have techniques for producing XHTML.

<MikeSmith> trackbot, reload my gin can

<trackbot> Sorry, MikeSmith, I don't understand 'trackbot, reload my gin can'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.

<mjs> http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#note-vs-rec

paulc: Looking at this process, which is part of decision policy v3 -- though this text has been there unchanged for some time. We seem to only ever get into the first stage here, where editor's make up a draft and declare Rec or Note.
... We don't seem to get to the stage where people object with the initial decision.

<mjs> here's a bug on polyglot being normative: https://www.w3.org/Bugs/Public/show_bug.cgi?id=9969

paulc: I think mjs was saying it might be better to have a sense of the WG before going to the Director. Aren't we going to get that sense when we go to CfC on the documents?
... You are suggesting we ask it so we don't get objections at CfC so we can ask it separately?

mjs: There might be people who are OK with it going to CfC either way and there may be people who object at the FO level until the end, even though the question has never gone to the full WG to decide. It's skipping a step to go from Editor's decision to Director without having the WG decide.
... I think it'd be cleaner to do it that way.

glenn: Agree with mjs on that. Are the last two FO's the same document?

paulc: No, there are two objections in one email.
... What if we did two CfCs on those two documents?

mjs: You can't have a CfC without knowing what the consensus position might be. We usually do CfCs when we think we know the default position and make others argue for it to not be. We could have a CfC and then still have an FO and *scribe fail*

paulc: If we did a vote and get only 10 responses, vs a CfC where we get 40. What if the vote was 4 and 4 or 6 and 4.

mjs: The process clearly says it's a preference poll because it's a process not a tech decision, so it's by individual not by org.
... It's really not much more complex than a CfC.

<mjs> and here's a bug on alt techniques being normative: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12726

paulc: The suggestion on the floor then would be to do two separate preference polls immediately on whether the two drafts (XHTML guidelines and Alt techniques) whether both of those should be rec track.

hsivonen: So did the chairs decide that there's no reason to invoke the process button?

paulc: Yeah.

hsivonen: Cameron has said that it's easier to algorithmically produce XHTML, but I've got experience in this that shows that's not true. It's actually easier to put an HTML serializer at the end of the pipeline than try to teach a generic XML producer to learn polyglot.
... A generic XML tool won't produce polyglot and polyglot makes it harder to serialize than to use a serializer that uses HTML.

<Joshue108> +q

Stevef: Say the document gets changed to a Note that I edit, then we still have normative text in the HTML 5 spec, then when do I get to make a decision going forward?

paulc: That's one of the arguments going into it, and you could object to HTML 5 going to CR.
... That's step one. mjs would it be useful for the co-chairs to follow-up with a note to the Director saying we're continuing to work on these items. He gave us homework and if we change our mind we should tell him.

mjs: Yes, we should probably tell him to hold off on those as the participants in those want to get a WG decision.
... The process set up for this does require having supports for and against having these on Rec track each write a brief rationale.
... Do we have that for each spec?

Cameron: I'll prepare a rationale on the pro side of polyglot.

hsivonen: I'll write one against since it's my objection.

paulc: Does anyone in the room want to write why Alt text shouldn't be on the rec track?

Lachy: Yes, I can do it.

Stevef: I'm willing to make a statement for it.

mjs: You can start writing those now, send them to public-html and the sooner we get that done the sooner we can get it done quickly.

<DanielAustin> Cameron: I'll help if you'd like

mjs: Wednesday of next week say? They can be short, a paragraph.

Cameron: Can I have two weeks?

mjs: We'd need another volunteer then.

Cameron: I'll see what I can do.

Joshue108: The alt techniques doc is a substantive document and I suggest the WG read it thoroughly before making a decision. I'm highly concerned that it gets drowned in the WG process.

matt: You can also FO for it to be Rec track, so you still have a way out.

paulc: The idea is to get some indication to give to the Director.

mjs: I'll write the Director with the current status.

paulc: I don't think the formal objections are going to go away, so I'll consider this item covered.
... So I think we have the five docs that will go to CR and decided the WG determined what to do on polyglot and alt-text. Now let's talk about Web authors, differences, Platform Accessibility APIs, and the Markup Language.
... When the base core spec goes into CR, what should happen with the Web Authors and diffs doc.

MikeSmith: The diffs doc isn't rec track and can just be a WD, at some point we'll have to decide what to do with it.

paulc: It says it's on the Note track. When we publish this do we base i--

MikeSmith: I'd say we need to republish the author doc. We don't have complete agreement that it should be a Rec track doc. I don't believe it should be personally, but others do.
... Simon is working on the diffs doc, it'd be a lot of work to do another version. I'm not sure it's worth the time to do it as there aren't going to be many differences that are just editorial.

paulc: The high bar would be to publish both as WDs as we go to CR, but I'm hearing it's not important for the diffs doc.

Simon: I don't mind redoing it for this publication.

paulc: So we should republish both as a WD?

SimonPieters: I believe that makes sense.

paulc: So that leaves us with HTML the Markup language, Mike?

MikeSmith: I'll do it.

paulc: So we'll publish the Markup Language as a WD.
... The last one is the HTML Accessiblity API guide. This is a DW and hasn't gone to LC.
... In some ways it's on a different timeline than other docs. What are the next steps?

cyns: It's not ready for LC. It was originally conceived as a Note, but we'd like it to go to Rec track.

paulc: I don't see why this would have to be co-published.

cyns: It's in active development so there are changes all the time. I don't see a reason not to when we go to CR on the other 3 that we would also publish the Accessiblity API as a draft as well.
... We have a few big changes that we were holding off on for the heartbeat draft, but we can get those in. Late November?

paulc: We'll know better after this meeting. You said it isn't on the rec track, but you want it to be? There's nothing in the SotD to say it's not, which means by default it is.

cyns: That's fine, I know there was some discussion of it.

paulc: There is a procedure for someone to object. The situation is that the Editor's have proposed that it be on the Rec track and no one has objected.

cyns: Great.

<MikeSmith> daq?

paulc: So we have 9 documents, 5 CRs and the rest as WDs published at the same time.
... Objections to that?
... OK.
... Given that we've talked about having a preference poll about alt-techniques and polyglot, I say darobin should hold off on working on them.

darobin: Happy to oblige.

paulc: We've done FOs. Now CR exit criteria.
... The CR exit criteria were proposed for Plan 2014, if there are no objections I won't review this now. The docs will point at the CR exit criteria. darobin do the SotDs do that?

darobin: I don't believe it does. I don't know if we're allowed to point to them or if we have to include them.

paulc: The 3 CR drafts need to be amended to have the CR exit criteria.

<paulc> exit criteria: http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

<cjones> +?

paulc: Features at Risk. Does anyone object to the items on the list of Features at Risk? Are there any items missing from the list?

-> http://www.w3.org/html/wg/wiki/index.php?title=HTML5.0AtRiskFeatures Features at Risk

jgraham: I have a general point and a specific point. I am wondering if we have some defined criteria by which we decide what can be on this list or can't be on this list? So far it seems like anything that people have suggested has gone on the list. That doesn't seem like great criteria.

paulc: I refer to this as a draft list and I believe your characterization is correct in that it's a wiki and that anyone who wanted to add something to the list did add it. Your second question is about procedure and we do need to get to consensus on what the features at risk are.
... When we do go to CfC for CR, there will be two elements: documents you can look at, which include explicitly the list of features at risk, and it will also explicitly ask whether we have consensus on those features at risk.
... What principles we use for what's on the Features at Risk is that it's not toxic to have things on the Features at Risk list because the criteria is if we had interop on those features.
... Having the Features at Risk has actually caused people to implement those features so they don't get cut rather than the other way around.

jgraham: For several of the things on those lists I believe we already have multiple, largely interoperable implemented features. I don't think we should put anything on the list when they've already become part of the interoperable Web.
... Specifically I'm looking at registerProtocolHandler. We've got implementations. I don't think it's appropriate to call it at risk from a spec point of view.

MikeSmith: I put it there.

<gitbot> [13html] 15darobin pushed 3 new commits to 06CR: 02https://github.com/w3c/html/compare/77652fdd84fc...1cd972ab1a00

<gitbot> 13html/06CR 149d6fa52 15Robin Berjon: bp conflict

<gitbot> 13html/06CR 14b81e1be 15Robin Berjon: bp conflict

<gitbot> 13html/06CR 141cd972a 15Robin Berjon: appcache at risk; CR exit criteria

MikeSmith: I didn't add it because I felt strongly about it other than Larry Masinter brought it up.
... I'm willing to retract it.

plh: I would object to removing that from the list with my IETF hat on. The IETF do have concerns about that and I'd like it to remain on the list while we're working it over with IETF.
... Not because of technical issues.

darobin: It's about potential security risk?

plh: Yes. I don't want to have to worry about having to remove it without it being marked Feature at Risk.

jgraham: If it's such a serious concern that it'd have to be removed from implementations, even then it doesn't seem like it should be marked as a Feature at Risk.

darobin: The at risk process lacks granularity. We might have to change it substantially, but it'd still have to be marked a Feature at Risk if we do have to blow it up.

hsivonen: Can someone explain to me what the purpose of at risk is?
... jgraham said there are interoperable implementations, but it appears you can get on the list from vague IETF concerns.
... It doesn't seem like there are reasons for Features at Risk. Why not put the whole spec under Features at Risk?
... I believe all of the navigation stuff is potentially not interoperable exactly as written, so if we took the criteria of having stuff that might not be interoperably implemented or implementable, then it should be on that list. It'd be horrible to remove it.

darobin: I don't disagree with you. I'd like to get this done without too much process. To answer your question: if we have to make some changes because interoperability problem then we're good to go if they're not too radical. I'd rather not have registerProtocolHandler be on the list because of IETF, but this might just be a good thing to be friendly to them.

paulc: Is there somewhere on public-html where IETF have listed their concerns?

plh: We talked about it on our last coord call and someone took an action to do it and send it to us.

darobin: Timeframe?

plh: I don't recall.

paulc: So, no.
... How are we going to evaluate anything without seeing it?

<hsivonen> it would be editorially horrible to remove navigation, but substantively, I don't want a REC that requires Web-incompatible navigation

plh: I have shared all I know, and said to them write down what you don't like. And that the best course of action at the time was to mark it Feature at Risk in that section.

paulc: I said 15 minutes before the end we'd switch to the mailing list discussion, so I'm going to pop up a level and ask: is there anything on this list of Features at Risk that people object to? And are there anything missing from the list?
... I answered the 2nd question myself with reference to CSS item and I believe scoped-stylesheets needs to be added.

plh: It's there.

paulc: We've had some discussion on objections to it, specifically registerProtocolHandler, was there any other?

jgraham: AppCache is interoperably implemented --

darobin: The reason it's there is purely procedural: we want to have the option of removing it and putting it in WebApps. If WebApps did a delta on this it might become a complete mess.

jgraham: That makes sense.

paulc: We have three examples of principles of what goes on the list: AppCache because it might be done in an extension spec, non-interoperable items and the registerProtocolHandler is that we may get evidence from an external organization that there are significant security problems and that it might need to be removed even if there is interop.
... Is there anything missing from the list?

hsivonen: What's the consequence of something missing on the list and then not fulfilling the CR exit criteria. I believe navigation won't fulfill the CR exit criteria.

paulc: If you have something on the list that wasn't identified you'd have to go back to LC.
... If you read Plan 2014, we're planning on doing that. We're not anticipating getting this list correct. We're going into CR for a long time on a large spec.

<MikeSmith> registerContentHanlder and registerProtocolHandler open huge security and privacy holes (bug raised by Larry Masinter)

paulc: The LC would be short, probably just a month. But any item we failed to get interoperable evidence we'd have to go back to LC.

hsivonen: Why have the list?

paulc: It helps drive implementations.

<gitbot> [13html] 15darobin pushed 1 new commit to 06html5_canvas_CR: 02https://github.com/w3c/html/commit/d46707fc59505c7155f6be90681451306716bbf8

<gitbot> 13html/06html5_canvas_CR 14d46707f 15Robin Berjon: CR exit criteria

plh: And it draws attention to the implementors. Having the entire spec be in Features at Risk won't do that.

cjones: ?? on the list doesn't meet the CR exit criteria. I'd like to put either a broad form submission algorithm or a method based switching with FTP and javascript means.
... I'll add it right now.

<MikeSmith> web+ and registerProtocolHandler

paulc: We're not going to make any decisions today, but we need it on the list as quickly as possible.

glenn: In the test suites I don't see any tests for ruby or the algorithm defined. I think that should be on this list as well for now.

Chris: There are parser tests which does the syntax and the semantics and layout are non-normative.

paulc: And if it's informative material you don't need tests.

<Zakim> plh, you wanted to talk about registerProtocolHandler

SimonPieters: hsivonen asked before what's the purpose of this list, and you said to drive implementations. That suggests that this is to micromanage the priority of implementations in browsers.
... I don't think it's appropriate to do that. If we want flexibility to take stuff out for various reasons then it makes more sense to put the whole spec on the list.

<glenn> there is a rather long "segmentation and categorisation of content" algorithm specified for ruby at http://dev.w3.org/html5/spec/single-page.html#the-ruby-element

paulc: Then 15 minutes on public-html list and it's use.
... Won't make decisions but get opinions on the table then do the testing session.
... Scribe?

rick: I'll do it.

paulc: Recess. Please be back before 2pm.

<mjs> http://www.w3.org/html/wg/wiki/TPAC2012

<cabanier1> scribenick: cabanier1

we need to put in a call to implementation

change to the agenda to go over this

minimum period for cr

paulc: I will go over the notes
... …we need a mimimum CR period
... … first item is plan 2014
... … we go into cr 4q 2012 and LCF 2014

paul: … this is the maximum CR

paulc: …another option is the one year option. minimum length is 12 month CR

paul: …if we choose the maximum cr, we can't get out of CR sooner

paulc: … option c is some earilier date
... … which is 2013
... … for some drafts
... … such as canvas and microdata
... …we can debate if we want the same data for everyone or separate dates

mjs: for the HTML5 spec, we already committed implicitly ourselves to a specific date
... … we can make if different for different spec

paulc: so we would pick the long option for the HTML core spec

krisk: the canvas one is the one that we can finish earlier
... … we have a lot of tests

<MikeSmith> eh?

krisk: … I have no opinion on microdata

<MikeSmith> have the microdata dom api tests not been checked into the repo?

paulc: I hear sentiment for a earlier cr exit for canvas

<krisk> Here is the Microdata tests from OPERA not tantek http://www.w3c-test.org/html/tests/submission/Opera/microdata/

<MikeSmith> krisk, ah OK those are the ones I was thinking of

paulc: … so, the current proposal is that for HTML5 we will say the minimum period is june 2014 and for canvas/microdata it's 6 month period

mjs: I would like to give a counterpoint for canvas
... … there are several items on the at risk page
... …especially hit regions

adrianba: I have one comment
... … the polyglot spec could make progress more quickly

<inserted> adrianba: what happens when the spec gets to PR - does it wait for Rec?

plh: the director has said that if you can show the features you depend on are stable then you can go to rec

cabanier: my fear is that the progress will be so long that by the time the spec is released it will be obsolete

cabanier1: …because the canvas specification is moving fast

mjs: polyglot has no user agent conformance. It just describes rules. I don't know how to write exit criteria for it

<hsivonen> great reason for not having Polyglot on the REC track

paulc: any other opions

adrianba: I didn't mean that polyglot requires parsing behavior in user agents
... … but writing a spec to map two parsers relies on those parser definitions being stable - if they were in flux then that would be an argument for not moving forward more quickly

paulc: for HTML5, maciej wants for go for the long time of 2014
... for the other items, it's unclear.

paul: I heard some sentiment to move early except Maciej

paulc: hit testing is the one he specifically identified

<mjs> maybe polyglot and alt techniques editors should first define their CR exit criteria

paulc: now we have to find the exit criteria with the editors
... and they have to find a minimum period
... … we won't preclude to go fast on html5, canvas and microdata to CR if the other two are slower
... … we can go CR with any spec

mailing lists

<cabanier> mjs: one thing I've been hearing, is that people want to do work outside the working group

<cabanier> mjs: … and complaints that the list is too noisy

<cabanier> mjs: … my job is to fix this. If every spec has its own list, it makes it very hard to follow

<cabanier> mjs: … I would like to hear what is bad about public-html

<Marcos> +q

<cabanier> robin: bugzilla email

<cabanier> mjs: poll -> 15 people

<cabanier> Marcos: too much email

<cabanier> mjs: poll -> 2-3 people

<cabanier> hsivonen: failure to ban people

<cabanier> hsivonen: people should be banned immediatly for one week

<MikeSmith> +1000 milion to what hsivonen just said

<cabanier> hsivonen: or people that keep going over the same thing

<cabanier> mjs: failure eliminate trolls -> 10 people

<cabanier> mjs: failure to stop ratholes -> 10 people

<cabanier> adrianba: the WG has a broad charter and diverse membership. it's hard for people to identify where they can contribute

<cabanier> adrianba: … I agree we don't want to fragment discussion but there should be a way to group topics

<cabanier> mjs: too hard to follow/small set of topics of interest -> 12 people

<cabanier> mjs: … there are 2 other WGs that have this issue.

<cabanier> mjs: … and they are happy with their mailing list

<cabanier> robin: even though webapps is diverse, it's all about API's

<cabanier> adrianba: perfectly happy is a bit over generalized

<annevk> WebApps 1) www-dom 2) public-script-coord 3) public-webapps 4) good use of Bugzilla 5) too hard to follow for trolls

<cabanier> darobin: moving process related discussion to another list would help

<fantasai> www-style also does subject-tagging

<cabanier> paulc: can you give an example?

<cabanier> darobin: in dap we did that

<karl> +1 to darobin

<cabanier> mjs: some people have told me that they don't want to see process related email

<cabanier> mjs: mix of process and technical ->15

<cabanier> hsivonen: the decision process seems optimized to make the chairs seem impartial

<cabanier> hsivonen: it should be about getting stuff done.

<cabanier> hsivonen: there should be no animosity between the chairs and the members

<cabanier> hsivonen: chairs are trying to protect themselves from criticism

<cabanier> mjs: I think things have changed; in first 2 years of WG, lots of traffic was wrt decisions being unfair. there might still be some distrust.

<cabanier> mjs: …is this relevant to the question?

<cabanier> hsivonen: if the chairs make more decisions, it would make the list less process heavy

<darobin> +1 to hsivonen

<cabanier> mjs: so you suggest that the chairs should decide contentious issues?

<cabanier> hsivonen: maybe no for contentious issues but for editorial ones. There is no reason to escalate those.

<cabanier> mjs: I agree for small issues. however it can become contentious if you decide an issue is small

<cabanier> paulc: so you're looking for less process by making earlier decisions and using the decision policy for big issues?

<cabanier> paulc: … and you think that is important?

<cabanier> hsivonen: yes

<cabanier> paulc: because you believe this creates less process?

<cabanier> hsivonen: yes

<cabanier> mjs: who believes that this decision process is important -> 10 people

<cabanier> glenn: how many people are satisfied with the list?

<cabanier> mjs: satifaction poll -> 2 people

<cabanier> Stevef: maybe having a digest for administrativa would be helpful. so you inbox is not filled up

<cabanier> jgraham: we have to make sure to not fragment the knowledge

<cabanier> jgraham: …because things are moved to other lists

<Stevef> odinho: yes

<cabanier> mjs: do people that this is a current/future problem -> 7 people

<cabanier> hsivonen: it could be that the solution is worse than the problem. (solution = multiple mailing list)

<cabanier> paulc: I want to point out that you're autosubscribed to the announce, public and html list

<Stevef> karl, talking about auto digest

<cabanier> paulc: it used to be that public-html got every update on bugs

<cabanier> paulc: …now it seems that people don't even want to see the new bugs

<cabanier> paulc: people want public-html to be heavily about technical discussion

<cabanier> paulc: we could move the CFC's to public-announce

<cabanier> paulc: … I prefer not to get digests because it's not helping

<cabanier> paulc: the chairs could do a better job of starting technical discussion

<cabanier> glenn: there have been 9500 message on www-style. public-html it's 3500

<cabanier> glenn: …this year so far. there's far less traffic on this list

<adrianba> also good evidence that people are staying away from public-html

<cabanier> darobin: I think people are complaining about the content (process decisions etc)

<cabanier> mjs: is there another distinct problem?

<cabanier> *silence*

<cabanier> mjs:

<cabanier> mjs: I want it to be a great place for technical discussion. Thanks for the feedback.

Bug 14689

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689

<cabanier> Norm: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689

<cabanier> Norm: there is no expectation for a normative change

<cabanier> norm: look at comment 35.

<adrianba> Comment 35

<cabanier> norm: the second to last comment

<annevk> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17976#c2 seems relevant for what needs to be done

<cabanier> mjs: could you give an overview of the technical issue

<annevk> there we go http://w3cmemes.tumblr.com/post/33421267632/scumbag-steve-is-worried-browsers-will-stop

<annevk> (old meme)

<cabanier> norm: xml core would like a non-normative note that this issue exists

<krisk> ...today browsers support text/xsl in the PI at the top of a xhtml document

<paulc> Proposed solution is in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c35

<adrianba> Associating Style Sheets with XML documents 1.0

<annevk> again, the actual solution here is addressing https://www.w3.org/Bugs/Public/show_bug.cgi?id=17976#c2 ...

<annevk> I mean, if you want to solve the problem

<annevk> you know

<cabanier> adrianba: could you not fix the document: http://www.w3.org/TR/xml-stylesheet/

<Norm> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17976#c2

<cabanier> darobin: I think it could start as an extension spec

<cabanier> darobin: can we agree to a non-normative note?

<cabanier> mjs: it's my recollection when we did xslt, this was the spec we looked at

<cabanier> mjs: …I don't know what problem we're solving with the non-normative note since we never needed it before

<cabanier> Norm: my recollection was that it was removed at one point

<cabanier> mjs: yes that was an earlier draft of html5

<cabanier> mjs: what problem are you solving:

<cabanier> Norm: since it's non-normative note, I'm not sure

<cabanier> Norm: the point of the HMTL5 spec. We would like to see some hint of this issue to be restored

<cabanier> mjs: I still don't understand the purpose of the note. why xslt style sheets

<cabanier> mjs: we can leave it up to the editors

<paulc> The request is to add this text to the following location in the HTML5 spec: http://dev.w3.org/html5/spec/history.html#read-xml

<cabanier> glenn: I support Norm's request and there is some language in the CSSOM spec

<cabanier> annevk: there is bug 17976

<cabanier> annevk: that lists the solution to this problem

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17976

<cabanier> DanielAustin: my proposal is to make this an editorial choice

<cabanier> Jirka: HTML spec describes what it should do when it encounters xml and xml-stylesheets is not mentioned here although browsers honour it

<cabanier> hsivonen: I think we can just put the language in there to put the concern that this feature is going to removed at rest.

<paulc> +1

<Jirka> +1 to hsivonen

<darobin> +1 to hsivonen

<cabanier> DanielAustin: I want to insert this note too. Since we use it in our systems

<cabanier> DanielAustin: … leaving it out seems like an omission to me

<cabanier> mjs: maybe we should have discussed xslt style sheet processing

<cabanier> mjs: no interest because lack of time

<cabanier> all: yes

<Stevef> main element spec https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

<Stevef> main element rationale http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction

<Stevef> data in support of the feature http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html

the main element spec

<Stevef> examples of use of the main/content id value to identify the main content area of a page http://www.html5accessibility.com/tests/HTML5-main-content/

<Stevef> data source http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/

<cabanier> Stevef: (listing the specs and the data)

<cabanier> Stevef: … the idea is that the main element is a simple structure element

<cabanier> Stevef: … it identifies the main area of content of the web page

<cabanier> Stevef: … like article, side, section, etc

<cabanier> Stevef: … but we don't have a marker for the main area because the idea that what is not marked up is the main content

<cabanier> Stevef: … so everything else needs to be marked up correctly

<cabanier> Stevef: … this can tie in with ARIA roles.

<cabanier> Stevef: …since we don't have a main element that can map to this role

<cabanier> Stevef: …the main element is a tradition and people have been doing it for a long time

<cabanier> Stevef: …people create this structure in their mind so why not add it to the structure

<glenn> fyi, re: HTML vs CSS ML traffic in 2012, see http://lists.w3.org/Archives/Public/public-html/2012Nov/att-0011/mail-list-traffic.htm

<cabanier> Stevef: … Search engines could use it to optimize their algorithms

<cabanier> Stevef: I would like to hear comments. I've had feedback from browser vendors that it's not hard to implement

<cabanier> Stevef: … but there has been not much excitement

<cabanier> Stevef: … however accessibility implementors are

<cabanier> Stevef: … also authors and users are keen on using this feature

<cabanier> fantasai: I believe <article> was meant for this. What is the problem with it?

<cabanier> Stevef: you can have many articles on the page. It's a different semantical things

<cabanier> mjs: the main content can't be an article at all. It's semantically wrong to use it for this?

<cabanier> hsivonen: the spec says so too. article is broader

<fantasai> hsivonen: e.g. it is also used for blog comments

<cabanier> mjs: does anyone here think it's a bad idea?

<cabanier> glenn: yes. (However I didn't read the spec)

<cabanier> glenn: it sounds too generic

<cabanier> Stevef: it used to be called 'main content' but after feedback from people like Maciej we shortened it to <main>

<LeonieWatson> +1 to the main element extension.

<cabanier> SimonPieters: Hixie refuses this idea

<cabanier> cynthia: the main content area is not always an article

<cabanier> DanielAustin: the majority of authors are doing this. There is a lot of demand for this to create this semantic difference

<cabanier> mjs: does anyone know why hixie doesn't want this?

<cabanier> jgraham: he believes there is no use case for having a separate algorithm.

<MikeSmith> aka process of elimination

<cabanier> jgraham: … subtract every element that has no semantic

<cabanier> jgraham: … also known as the scooby doo algorithm

<cabanier> everyone: we believe so too

<cabanier> paulc: will that resolve to more than 1 element?

<cabanier> jgraham: yes

<glenn> naive question: why not use class or role?

<fantasai> jirka: Suppose I have a very simple web page with no navigation, etc., just content

<fantasai> Jirka: Does this mean I have to add a <main> element to it now?

<fantasai> Stevef: For a11y, need to be able to skip navigation etc. to the beginning of the main content. Currently use e.g. skip links for it

<fantasai> Stevef: That's the main use case

<fantasai> Stevef: So in your example, you don't need a <main>

<fantasai> Stevef: It's easier to mark up just the <main> content than to rely on everythign else to be correctly marked up

<cabanier> odinho: you could say that the main element is not needed by elemination

<cabanier> odinho: BUT it's much easier for authors to use such a thing and you often find that they already do it

<fantasai> odinho_: You already need such an algorithm for pages that don't have a <main>

<cabanier> odinho: I don't see a problem apart from introducing new HTML elements

<cabanier> odinho: … jumping to the main content would be easier

<cabanier> odinho: .. especially if different a11y tools start implementing it

<cabanier> fantasai: I think these are good points.

<cabanier> hober: I don't have a strong feeling about this. Steve did a great job on researching this

<cabanier> DanielAustin: a really good use case is to strip off content for screen reader

<ddorwin> scribe:ddorwin

Update on testing TF

kris: presenting slide given to AC
... 11907 tests with consensus are correct and valid
... presents new contributors since TPAC 2011
... public-html-testsuite@w3.org list. It's pretty quiet. Feel free to participate.
... … new activity: http://testthewebforward.org
... Presents Testing Task Force Status showing test results. 17 tests only pass in one implementation. 11 do not pass in any
... We do not have enough tests.
... … everything at risk needs tests
... questions?

paulc: regarding the page showing test status - what is the correlation of acceptance of tests and pass rates

kris: WebIDL tests haven't been accepted.

paulc: If I saw this chart for the unapproved test, I would see more red. Would I see some green?

??: Yes, some green. Authors of the test usually pass the tests.

jgraham: … A lot of the passing tests are parsing tests. We have 4 good parsers.

kris: A number of canvas(?) tests.

Mark_Vickers: Do you have a sense of the goal? What is enough? Do you have a sense of coverage?

kris: People have created tests as they add features to their browsers.
... … What we don't have is tests across the specification.

Philip: Tried to determine what from the specification the tests are trying to cover.

plh: 2400 files, but only 700 are covered
... Some of the test files have many tests in them

On screen is a table showing the data. Includes caniuse data in column 3.

jgraham: the goal of the W3C is to lead the way. One of the goals is to make sure the standards are interoperable. More than getting individual to standards, we want to make them interoperable. We want to get rid of bugs that make it difficult to write interoperable apps.
... If there are tests that show a problem with interop, we should have a way of accepting that test regardless of process.
... It's not necessarily clear how we balance those two concerns. We don't want to be dropping/refusing tests because we have an immediate goal to get to Rec.

kris: With the 2014 plan, we have a risk that we end up with tests that no one passes or only one passes

Mark_Vickers: I think we have to split off the goals of testing for the purpose of the publication process vs. testing for developer support (i.e. webplatform.org). I wouldn't want to have to burden publication by saying every possible test. I would like us to take on the non-spec goal.

jgraham: I agree, but we have to have a way of separating out the tests that everyone has to pass before we get to rec.

<Zakim> cyns, you wanted to ask about aria integration testing

shepazu: We have to have the discipline to continue doing that

<Mark_Vickers> sorry i jumped the queue

cyns: Asks about Aria. It's being tested against HTML4, not HTML5. We have a huge set of tests.

kris: Currently all tests are in one big folder that spans multiple specs. we should separate them out.
... I'm not sure where the accessibility tests are.
... We really need to submit them to the repository.

cyns: They are a bit complicated
... Michael Cooper is the person to talk to.

kris: Polyglot has a similar problem.

krisk: Problems with screen readers on browser/OS combinations

cyns: We're not using screen readers.

krisk: Could definitely use experts on this in the testing WG

paulc: I don't believe we have transparency about the table and is it available or when it will be available. Is there a plan for a plan?

krisk: It's tough to produce this table and took a lot of hours.

kris: Put metadata in the tests (?)

paulc: With our HTML5 public permissive CR exit criteria, identifying the places where we have some public evidence of interop is the best way to show where we need more tests to get out of CR. People may still want to provide more tests in that area. Going to testthewebforward and saying these are the places we need tests because we don't have any evidence would be curcial

jgraham: Unless we know which tests go with which sections, it's hard to tell which sections need more tests. Quantity of tests is not necessarily a good measure.
... Doing this work is hard. There is no magical process or metadata. Writing tests is hard creative work.

kris: Agreement on changing directory structure
... Approved vs. submitted is important.

jgraham: Approved vs. submitted has caused problems, such as when you move files around.
... Preference to have directory structure based on where in the spec it is.
... Have approved vs. submitted as metadata
... Use scratch folder or branches for stuff people want to check in

<gsnedders> Or separate repos entirely.

Mark_Vickers: Related to testing devices & the work on WebDriver - Is there a goal that all of these should work with WebDriver.

<gsnedders> (Given we're using a DVCS)

krisk: There is not requirement that tests must work with WebDriver.
... AppCache is an example of something that couldn't be done with WebDriver. Playing a video and listening for sound as well.

jgraham: You could write a harness to run the tests. For JS tests, it's easy to run them without WebDriver. There are hooks that enable this.
... We prefer ref tests. These can be implemented in WebDriver.

krisk: Early our principle was that we wanted tests available to everyone and to support everyone.

SimonPieters: Submitted and approved directories - the point is that things in Approved have been reviewed. But we don't have a good process for reviews and revising the tests after review.
... Proposes using branches and tests in the main branch are always reviewed.

<gsnedders> (And the experience in general is we never actually review half the tests, they just get moved through by virtue of no objections)

????: Do you have a review tool?

SimonPieters: Yes.

krisk: Would like to have a review tool.

jgraham: If we move the workflow to github then push to Mercurial, that gives us a review tool. Using the github review tool, however limited it is.

discussion of how this would work

Mark_Vickers: In terms of tackling the large problem, there are a few paths. You mentioned donation. Another is crowdsourcing through testthewebforward.

<JonathanJ1> we were already hosted many W3C WG meeting. DAP WG, Media Annotation, MWBP WG ...

<JonathanJ1> OMG

Mark_Vickers: Other ideas: 1) Break down the spec into sections and assign responsibility for testing a section to companies - to figure out a test plan, etc. 2) Outsourcing - pay for testing to be done. Might have to get additional funding, but it might be worth it.

krisk: I don't think anyone is opposed to getting companies to do things.

kirsk: Hasn't been a lot of stickniess with testthewebfordard. Usually a 1-day thing.

jgraham: Of course getting people to write tests is good, but from a browser POV, I don't think it would work. The priority is to write tests when they are implementing. It seems unlikely they would pull people off implementing to write tests.
... Regarding hiring people to write tests, the trick is to make it good people. There is a strong concentration in browser vendors and other places of people that are good at writing tests. That's not always the case.
... The places where tests are missing are the complicated bits.

paulc: Describes previous expereience.
... A majority of the 25,000 tests in the XML Schema WG were written by NIST. Not an implementor, but they had test writers.
... This is part of plan 2014
... Do we have any sponsorship money left?

<Mark_Vickers> http://www.w3.org/Consortium/Recruitment/#qmgr

plh: I don't have the answer yet. Hoping by the end of the month.
... The link from Mark_Vickers is not the right posting.

<Mark_Vickers> oops

krisk: I feel we have tapped all our resources, in terms of browsers participating.
... Maybe there is something that could be done in terms of membership.
... Find organizations that care about testsing

jgraham: We have not tapped browser vendors. We could do better at getting browser vendors to write tests that others can use.

<gsnedders> And release the ones they have.

jgraham: We should have a conversation about whether there are things we can do to make it easier.

DanielAustin: In previous incarnations, we reached out to the HTML Writers Guild. I don't know whether we've reached out to them.

jgraham & krisk: not aware

<DanielAustin> http://hwg.org/

mjs: Looking at agenda.
... remaining items: issue 204, remaining issues, Alt Guidance, Other FPWDs.
... Asks if there is interest in these.

skipping 204

Tracker Requests

paulc: Tracker Requests are bugs that have been addressed by an editor but someone disagreed with and added the Tracker label.

paulc/Robin: None of the current tracker bugs were disposed of by a current editor

mjs: is anyone interested in each of these.

paulc: drag-and-drop processing model - could not find anyone in this meeting. We don't have the right people.
... 18384 adaptive image mechanism. I think the chairs should deal with this.

<DanielAustin> link to this tracker list?

paulc: 18384 - Chairs to investigate whether to deal with the tracker request

mjs: 13614 <th abbr="">

<matt> Tracker Requests

SimonPieters: That bug appears to be fixed. Should we remove Tracker

<DanielAustin> thx

<matt> Tracker Requests

concern about adding more text that is meant to be read out (related to i18n)

<fantasai> into an attribute

Chairs will determine the providence of the Tracker Request 13614.

mjs: 13409 - Defining Entity references for characters in XHTML

The room tries to figure out what it is about.

mjs: i believe Sam said he would comment on this, and that it's an interop issue.

Reviewing the comments in the issue.

mjs: This is a feature request.
... Most of these are extension specs, so they will likely be rejected unless someone makes an extension spec.

<darobin> [for https://www.w3.org/Bugs/Public/show_bug.cgi?id=13614 TrackerRequest was added two weeks ago http://lists.w3.org/Archives/Public/public-html-bugzilla/2012Oct/0350.html]

mjs: … or 5.1.

Alt Guidance and Alt text in the HTML5 Document Part 1: Analysis of Guidance

paulc: We don't have the right people

Other FPWDs

mjs: Anyone have such a document and want to propose it here?

paulc: What is the process for getting extension specs to FPWD?
... It's not clear what the next step is after the WG gets a request.

paluc: Travis suggested doing a CfC.

mjs: How we have handled FPWDs in the past: First, we expect there to be some indication that the document is ready for FPWD. We have asked in a few cases to make it explicit to show some minimal number of independent contributors to the draft in order to show it is not just a 1-person project. Previously, we have required 3 independent contributors. A contributor can be someone who has filed a bug. We do a CfC. Usually the bar for objection is pretty high.
... This is outside the scope is a valid objection, but I don't like this generally is not at the FPWD stage.
... We haven't written down the process because we haven't expected a lot of them. But now we might with the new extension process.
... We may need to step back and create a process.
... Does anyone have comments on what should be the bar?

darobin: I don't disagree that we might need a little bit of process, but we did discuss having less process this morning. It would be nice if process was minimal and maybe rough consensus.

SimponPieters: I think we should ask the question what is the implementation interest for what the spec is trying to target. For example, if the feature is targeted at search engines, we should ask if there is search engine interest.

SimonPieters: If there isn't implementor interest, we should drop the draft even if there are 10 people involved.

hsivonen: The general public will think that things this group publishes will be part of HTML5. We should have a filter at the start of the process. For the conformance classes addressed by the spec…(?)

Travis: I want to see less process and us having lots of extension specs because it gives us the opportunity for us to pick and choose and for the most popular ones to succeed. CSS 3 as an example.
... We're already there in the public eye and browsers are not willy nilly with what they pick.

DanielAustin: Want to offer a counter example to previous speaker saying we should wait for implementor interest. if we had done that, we wouldn't have iframe.

DainelAustin: I'd like to think of it as users driving implementors to what they need.

mjs: (implementor hat): It is annoying when specs are published that are very likely never going to be implemented by anyone but purport to provide conformance criteria.
... … On the other hand, when someone is at the FPWD stage, I don't know whether it's something that we'll want to implemented.

<cyns> +1

mjs: … Apple doesn't speak about future plans and wouldn't want the process to involve explicitly saying I'm interested in implementing this.

hsivonen: I'm not expecting any implementor to commit to anything. Rather, I'm expecting implementors to say this is a good idea as a spec. But not looking for a commit.
... As for iframe, I though that came about from IE4 being developed at the same time as HTML4 and emerged as a feedback cycle.

jgraham: I don't think that we should be putting things in FPWD just because we think that then the group might be able to force implementors to do things that certain members want.
... I don't think the HTML WG is a good proxy for what authors want.
... I don't want to have that type of forcing function just because it's in the group process.
... Specs should have to survive on their own merit and not via branding

<DanielAustin> historical note: iframe appeared in IE4, was repeatedly rejected as a proprietary extension, until members complained that they really wanted it

paulc: (Microsoft hat) The last thing we want is that FPWD means a majority of browser vendors have agreed to implement it.

<odinho_> DanielAustin: Those were also very very dark times... More or less everything is different today.

paulc: I think a majority of the extensions fall on the end of the requirements that mjs suggested.
... MSE and EME are examples.

<DanielAustin> not as different as you may think :)

paulc: Gives example of extremely credible effort done by one person.
... For those specs that don't meet the requirements, please start saying so on the list.
... Media TF is going overboard to make sure it doesn't ask for FPWD before it's too early. Making sure to get the design right and flatten as many bugs as possible before FPWD.

<cyns> +1 to say that there has been lots of discussion of the main element in the a11y-tf and in pf.

jgraham: One thing that made <main> more credible is that it appeared the author had obtained buy-in.

<jgraham> from implementors

mjs: This is a lot easier to consider concretely than in abstract case.
... For anything we have published, do you think it would not have passed?

hsivonen: I think RDFa would not have passed.

mjs: Disagrees

discussion of whether HTML+RDFa is implemented

and whether it's use of syntax vs. the spec.

mjs: Main Content and media specs have traction
... Unclear whether longdesc has implementation support but …
... We probably don't need to create a process for a problem that doesn't exist.

paulc: If you look at the report the chairs gave to the AC, there is a reference to a F2F meeting in April 2013.
... We're expecting the new charter to say F2F meetings twice per year instead of once per year.
... Looking for a place in Silicon Valley. Possibly paired with WebApps.
... If you want to volunteer a host site, talk to plh.
... Approximately April 22nd.

DanielAustin: We are looking at hosting (PayPal)

paulc: Thanks to WG members. Thanks to scribes.
... We'll see you on public-html

<matt> \

- DRAFT -

HTML WG f2f

02 Nov 2012

Attendees

Contents

MultilingualWeb-LT

i18n bugs

Concerns with ruby markup

i18n bugs

Preparing for CR and WG Status

minimum period for cr

mailing lists

Bug 14689

the main element spec

Update on testing TF

Tracker Requests

Alt Guidance and Alt text in the HTML5 Document Part 1: Analysis of Guidance

Other FPWDs

Summary of Action Items

Scribe.perl diagnostic output