HTML WG face to face in Santa Clara, breakout session -- 05 Nov 2009

<prolix> like label on command

<prolix> contentinfo is broader than <addres>

<prolix> there isn't a 1-to-1 mapping between <address> in HTML5 and contentinfo in ARIA

<MikeSmith> prolix: should comment on #aapi instead

<wendy> fo: 3 types of canvas accessibility: decorative, informative, interactive

<wendy> (frank olivier)

<wendy> prolix--yes, i can do that

<wendy> i'm wendychisholm at skype.

<wendy> ...if we created dom underneath, overload "fallback text."

<wendy> ...that works for decorative and informative (in case of table with data), but there are cases where you want fallback text, but also want better text.

<wendy> ...want to see the table as well as the canvas. a way to know there is accessibility info within canvas.

<wendy> ?? is it nested like object?

<wendy> cs if you can render the content, it won't render the fallback.

<wendy> ... if you need the accessibility information but your browser supports the primary content, you can't get to it.

<wendy> ... part of the solution is better browsers.

<wendy> fo: could show both. or let the user choose.

<prolix> that's what the noframes content in the web IRC interface says - "you need a browser that supports frames and javascipt. full stop'

fo: dom underneath allows you to park it under the element and not create another dom.

cs said something bout aria...

scribe: labelledby

cs: informative canvas--have something like aria-describedby that has some sort of text that is a sufficient equivlalent.

<prolix> fallback could be an ARIA-enabled widget or tree graph

fo: 2 layers of informative canvas. 1 is a simple text equivalent/fallback works. 2 more complex (a graph of data) with data table as fallback.

<prolix> the "family tree" example

fo: informative contains data that is read-only. interactive can contain data the user can modify.

?? aria could be processes separately.

fo: there are accessibility tools that will read that information.

sf: are there any at that access it?

fo: fangs reads everything from the canvas.
... I think nvda does it. (unsure)
... not a big problem to update at software to look underneath the canvas.
... how do you know it's fallback and not alternative representation.

sf: question about the spec (missed)

fo: couple weeks ago a comment that elements under canvas should be tabbable. talks about color picker.
... could tab into form elements behind to change color values.

sf: what about non-at user who wants to use the keyboard?

fo: if someone wants to recreate the ui controls using canvas (more stylish looking controls), i cant use os theming on them.
... would have to handle focus highlights.

cs: could a browser fix that?
... flash accesses that.

fo: if you have a high contrast mode on your computer, there are ways to do it (to go into that mode).

<prolix> http://esw.w3.org/topic/HTML/AddedElementCanvas

cs: ie messes with css.

fo: overwrite the stylesheet.

cs: high contrast mode turns off a lot of css.

fo: could give canvas access to that. a color mode in canvas--a background ui control color you can specifiy.

cs: available to you as a windows app.

fo: solved in the css color module.

(should be solved....)

<JF> anything on that page in particular greg that you want me to highlight?

<prolix> high contrast equals what - the opposite of the rgb values used or user client-side preferences?

cs: access to the operating system focus.
... in windows when you tab into a text box it's the same focus that you get when tab into a windows dialog.

?? description of how apple does this?

cs: it's not based on the operating system.
... there are ATs that will change how things look. done at the OS level. would be nice to support.

sf: to be considred ccessible, need to provide that.

?? want access to the themeing api.

scribe: describes the set of intrinsics.
... everyone has them. lowering those to the browser is a huge undertaking.

cs: as an author, not asking to have access to that.
... if i put focus on an element in canvas, i want the same behavior that happens in html.

<prolix> some users will want the canvas, but need to be guided through it (users of supplemental speech, for example, for those with cognative processing issues)

cs: so if user sets, then the system variable are honored.

<prolix> or those with a limited point-of-regard

<wendy> scribe: wendy, scribe

<wendy> sf: proiding programaitc focus

<wendy> eep.

<wendy> sf: providing programmatic focus

<wendy> cs: works on most elements, but not on canvas.

<wendy> ?? canvas is just a bitmap. not providing a form element but something that looks like a form element.

<wendy> cs: they have made it accessible by using msaa.

<wendy> ?? msaa or theming apis?

<wendy> cs: not sure

<wendy> sf: programmatically focusable areas.

<wendy> fo: you could have a canvas context method, draw focus rectangle tha tuses the os theming to draw a rectangle on the canvas.

<prolix> CSS user preferences need to be supported

<wendy> ... canvas with 10 ui elements and you want to tab between then, author would have to make the keyboard tabbing.

<wendy> cs: that combined with aria markup should be most of what is necessary.

<wendy> fo: creating hidden ui controls underneath, need a system focus rectangle and using aria to expose properties and behaviors to ATs.

<wendy> ... only using canvas to style from scratch your ui controls.

<wendy> ... not limited to only one ui control per canvas, but can have several.

<wendy> ?? seems like it's a hole tha tyou keep digging--how many apis do you add to the context?

<wendy> ... if just drawing focus rings, but if there are other aspects of ui decisions that theme will change, then you will need to expose a huge set of things.

<wendy> ... in some sense, css is trying to solve.

<wendy> fo: i don't think we can get to the point, where you use the system ui colors.

<wendy> sw css color module defines a few hard coded names that map to windows concept, that will change as you change the themes.

<wendy> ... may be deprecated.

<wendy> cs: that was the design goal of those.

<wendy> (sw from apple)

<wendy> fo: creating a mini dom makes sense.

<wendy> ...the only new method is a way to draw focus rectangle.

<wendy> sf: it's a common use case to draw a focus ring, but also want to define an interactive area.

<wendy> ... if it comes with focus--that's default.

<wendy> ... then they dont have to worry about addng that.

<wendy> cs: that ui works like the other uis the user is used to.

<wendy> fo: also discussion of something like a click map.

<wendy> ... if i have 10 user controls, i can set up 10 clickable areas and can get an event and handle it.

<wendy> cs: support ismap? use the same image map?

<wendy> fo: think that goes a little too far.

<wendy> ... think the author can handle the events.

<wendy> cs: can an image source point to a canvas?

<wendy> ... create an overlay?

<wendy> fo: yes, could create an overlay.

<wendy> cs: interactive canvas--ui contorl is the tricky one.

<wendy> cs: difficult to come up with a paradigm that makes sense--that works as canvas does now but works with how html was/is going.

<wendy> ... does dom under canvas seem natural?

<wendy> fo: shows demo

<prolix> "The CSS2 System Color values have been deprecated in favor of the CSS3 UI 'appearance' property for specifying the complete look of user interface related elements" (http://dev.w3.org/csswg/css3-color/#css-system)

<wendy> ... three day weather forecast.

<wendy> ... "click here to switch to degrees F" 3 suns each with temp in the middle (in Celsius).

<wendy> ... if you just draw pixels into the canvas, you won't get any information for the canvas.

<prolix> so it needs live regions and accessible controls...

<wendy> ... what i've done is create a tiny dom underneath.

<wendy> ... fangs is a screen reader simulator

<wendy> ... looking at that to see what it's giving for this page.

<wendy> ... s/this page/this canvas

<wendy> cs: what's the diff between what you've done there and having fallback html w/in canvas tag?

<wendy> fo: could add a text box and interactive elements.

<wendy> ... more example of an informative than interactive.

<wendy> ... james craig did a demo with checkbox within canvas.

<wendy> sw: makes text accessible to AT but invisible to the screen?

<wendy> fo: take the fallback context, erase it, add in a new dom under the canvas, that has interactive elements.

<wendy> cs: kept the interaction in sync?

<wendy> fo: yes, james draws a focus rectangle himself.

<wendy> cs: he was toggling the visible check and the hidden.

<wendy> sw: what changes needed in html5 to support this?

<wendy> fo: mini-dom: nothing really. it's the canvas subtree.

<wendy> cs: canvas subtree and interaction between canvas and other elements managed?

<wendy> jf: james demo uses javascript.

<wendy> sw: any sync would need to be done by the script.

<wendy> fo: he was supporting events, drawing focus.

<wendy> cs: this approach does meet the minimum bar of accessibility--it's possible to make an accessible product.

<wendy> ... however, is not easy, intuitive, such that developers would do it.

<wendy> sw: argue that javascript to write checkbox and handle events not intuitive either.

<wendy> ?? someone is obviously writing it for the rest of the UI.

<wendy> sf: doubling the work?

<wendy> cs: seems like keeping it synchronized would be hard.

<prolix> could CANVAS support an "order" attribute? order="targetID,targetID2,targetID3" or order="targetRole, targetRole1, targetRole2"

<prolix> that's the SVG adition to the XHTML Access Module (http://www.w3.org/TR/xhtml-access/)

<wendy> discussion about how much work are developers going to do to add accessibility to custom controls.

<wendy> fo: argues that if it's 8 days work to create their own custom contorls, 2 days work is no big deal.

<wendy> accessibility folks say, "we've heard that before and unfortunately, that will take a lot of education to get people to do that."

<wendy> fo: counters, most people will not create uis from canvas from scratch, they will use libraries and the libraries will be accessible.

<wendy> wc: they better be!

<wendy> fo: no matter what we do, people will have to do additional work to make canvas accessible.

<wendy> ... currently, it's an additional few lines of code.

<wendy> ... perhaps give them an api that will make it 1 line of code instead of 4.

<prolix> testify, sister, testify!!!

<wendy> discussion about alt and that isn't even used.

<wendy> fo: but you are asking for a technological solution. i'm giving you that.

<wendy> ... otherwise, you are asking for the impossible.

<wendy> cs: designing the api is part of the api and not some tacked-on thing.

<wendy> ... not an unpleasant task for devs.

<wendy> mm: wish list

<prolix> keyboard support, device independent event triggering, for a start

<wendy> mm: wish-list++ add accessibility info out-of-band--you have a toolkit that doesn't suport accessibility. be able to add info, map to html controls, etc.

<wendy> sw: we have a good solution.

<wendy> ... if you inherit an app, you already know which elements you will need to shadow.

<wendy> ... if it's well-factored, it can create the button in the subtree.

<prolix> can you use XBL on CANVAS?

<wendy> ... if you have a routein to focus a button ont he canvas, has it on the subtree.

<wendy> cs: not saying not workable, thinking about how to make it more adoptable.

<wendy> sw: well-factored, yes.

<wendy> ... it's a drawing api. could make it oo but it's drawing.

<wendy> fo: there is not perfect solution. lots of solutions that all have sub-optimal outcomes.

<wendy> ... what we have currently is a good road. will people drive on that road? don't know.

<prolix> converge on and learn from lessons of SVG

<wendy> ... made it as easy as possible. but shouldnt put too much of a burden on ppl.

<wendy> ... compared to what ppl doing today, should be ok.

<wendy> cs: it would be nice in the future, perhaps in html5 timeframe, to have access to accessibilty apis from javascript.

<wendy> ... for something like canvas, be able to say "this box is a button."

<wendy> .. understand harder. if we go with a dom approach, that the other possibility is not locked out for a future version.

<wendy> fo: interesting way to do that is to tag the canvas element with a property that says, "accessibility provided by method x."

<wendy> ... think there are lots of ways you can go.

<adrianba> +1 on the point about having accessibility apis from javascript

<wendy> fo: shows the dom of the demo

<prolix> adrianba, this is one reason why i'm going to suggest canvas implementation via script libraries if the Rich Web Application Incubator Group's final report's recommendation that a working group be established to continue to investigate the area is formed (http://www.w3.org/2005/Incubator/app-backplane/XGR-app-backplane-20091030/)

<prolix> could use the SVG order attribute model referenced above

<prolix> aria-role="button"

<wendy> discussion about how to synchronize the shadow canvas with the html elements so that someone who is sighted and using the keyboard can operate the controls in the canvas.

<wendy> cs: describes counter proposal.

<wendy> talking about marking coordinates with roles.

<wendy> ?? need to be able to do all of the things we do with the dom.

<wendy> cs: counter proposal is to 1. direct api access 2. is there a way to make it so that it's possible to use the html elements but have them look as spiffy as theyw ant.

<wendy> sw: in webkit you can take a button and make it look however you want.

<wendy> ... there are extensions to css.

<wendy> .. or you can make a div, draw anything you want into it and add an aria attribute.

<wendy> ... canvas is for ppl who say, we want to draw other things differently.

<wendy> cs: my concern ppl taking that jump too easily.

<wendy> ?? is it likely that we're going to add features to html that will satisfy those same people?

<wendy> ?? css will never help someone wh ocan do a better tetx editor.

<wendy> cs: right.

<prolix> amen

<wendy> ?? we need a solution lets someone who wants to do that much work nd also wants to make their work accessible, we should let them do that.

<wendy> cs: yes, make it possible and as pleasant as possible.

<wendy> ?? as implementable

<wendy> cs: making it so that there are fewer cases where ppl need to do that to get their artistic expression.

<wendy> mm: the technology will be used in ways no one in this room has thought of.

<prolix> something EXTENSIBLE

<wendy> ... my big concern is that the solution we have will account for as many of those eventualities as possible.

<wendy> fo: anything you can do with dom, you can do within canvas.

<wendy> sc: let's mke sure that we've covered everything.

<wendy> cs: hgh contrast, yes.

<wendy> sc: options w/in browser--zoom, etc.

<wendy> cs: pixel zooming should work.

<wendy> font size an issue?

<wendy> sc: so we've covered keyboard access, screen readers, etc.

<wendy> cs: does canvas spec need to talk about browser and os settings.

<wendy> fo: could be at least one paragraph in the spec.

<wendy> js: we suggest to ua wg that these are on the horizon.

<wendy> fo: we've covered the major use cases of canvas.

<wendy> ... everyone seems to be ok to use a dom.

<wendy> clarification that the shadow dom is not like iframe, but is child of canvas element.

<wendy> fo: need good documentation both for devs and at dev.

<wendy> ... think only have one new method: draw focus system rectangle.

<wendy> sw: the alternate is you could put in an invisible element and focus on it.

<wendy> fo: don't think we need to redesign the api.

<wendy> ... and a way to clear it.

<wendy> cs: if using a screen mag, need to follow focus.

<wendy> fo: os should handle the case. in windows, the bitmap will have direct coordinates.

<wendy> will a rectangle be sufficient or also need other shapes?

<wendy> discussion of focus rings/rectangles.

<wendy> have a layer above the canvas.

<wendy> fo: people are handling clicks on canvas and taking an action.

<wendy> cs: if the focus moves, the viewport needs to move with focus.

<wendy> fo: we can do that.

<wendy> sf: the magnifier has to understand that is a focusable rectangle.

<prolix> good idea, cyns

<wendy> sw: since the focus is programmatic.

<wendy> ACTION: cs and fo talk about how porgrammatic focus works under the covers in microsoft. [recorded in http://www.w3.org/2009/11/05-html-wg2-minutes.html#action01]

<wendy> ACTION: sw talk about how programmatic focus works under the covers in apple. [recorded in http://www.w3.org/2009/11/05-html-wg2-minutes.html#action02]

<wendy> sf: how to get access to text...cursor (missed it)

<wendy> cs: needs to be a way for input focus to be synched (like keyboard focus)

<prolix> thank you all

<wendy> all done!

<prolix> as for theCSS control of UI colors and such, check http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JulSep/0348.html

<tantek> FYI - anyone in room 1243 - the HTML media types session has been canceled due to being covered during the TAG joint meeting

<SCain> We were wondering...thanks for letting us know

<weinig> http://nerget.com/edgeDetection/

<annevk> you guys are done with the <canvas> discussion?

<cardona507> no

<annevk> ok :)

<annevk> I missed the first bit discussing the link header and nothing much was minuted

<annevk> what happened so far?

<weinig> tantek: http://nerget.com/edgeDetection/

<MikeSmith> scribe: timeless

RDFa and Microdata

<scribe> ScribeNick: timeless

Tantek: ...
... html has been developed at the w3c
... to describe meta data
... meanwhile HTML5 has been developed at the w3c
... which also ...
... and for html5, use cases were developed to ...
... and IanH developed a way to express meta data

<Julian> http://www.w3.org/TR/rdfa-in-html/

Tantek: There was a draft of HTML5 with RDFa developed and ...
... pub status for HTML5+RDFa: First Public Working Draft

Glenn Goldstein, MTV networks: ...

scribe: I want to get a sense for the scope of microdata
... Microdata could be used to hint to search engines for discoverability
... To inject data into the document that will be rendered out by e.g. JavaScript

Tantek: ...
... one more point that's relevant for the discussion
... there was a joint meeting held with the TAG earlier this week
... my understanding was that there were plans to factor the Microdata syntax out into another document?

MikeSmith: there has not been a decision

IanH: ...
... this was regarding vocabulary

tantek: then this wasn't what I understood from yesterday's tag meeting

Julian: ...
... there was something which takes out the syntax from the html5 spec
... there is a complete spec which has the html5 microdata removed
... and the working group asked for a counterproposal for keeping it in
... last week
... and there's been no such counterproposal

MikeSmith: Manu offered to write a counterproposal

MJS: I think Ian is planning to do one
... and I don't think it makes sense for Manu to argue against himself

Julian: do we have a timeline for when the counterproposal can be expected

IanH: what was the deadline?

MikeSmith: do we have one?

IanH: it's probably about a month
... if there is one, then it will probably happen

tantek: My understanding that Tim made was that he wanted microdata separate
... his reasoning was that the html5 spec was relatively big
... and it would be nice to separate things out that could be kinda big

MikeSmith: the idea was to allow microdata and RDFa to be able to stand on their own and compete...
... so if RDFa is separate, then microdata should be separate

[ scribe: "compete" was not what MikeSmith said, but scribe couldn't catch what was said ]

MikeSmith: it's worth mentioning that both could be used
... there's no name conflicts
... when hixie did the original draft, there were one or two name conflicts
... but that was resolved

<annevk> (the deadline mentioned earlier is December 2)

MikeSmith: today, they don't really conflict with one another
... they can both be used

Hixie: we're already recommending a third one
... class attributes and microformats

MJS: I think microdata and RDFa have someone different design centers

<annevk> (see http://lists.w3.org/Archives/Public/public-html/2009Oct/0952.html )

MJS: and I think it might be nice to let them play out in the market
... microdata is relatively good for representing simple data
... RDFa is good for expressing the complete RDF ...
... different people see values in both of those approaches
... i don't think we need to bet on one or the other
... a helpful decision would be to publish HTML5+RDFa
... and publish HTML5+microdata
... and let them be used for a bit
... and then at some day we can pick (canonicalize) the winner

<Kai> +1 to mjs

MJS: The HTML5 spec has a provision for binding external modules
... The current HTML5+RDFa draft takes use of that provision
... so it's kind of a question of whether validator profiles will take into account such specifications
... will they put them into

tantek: does html5 define a validation model for extensions?

Hixie: I don't understand what that means

MJS: HTML5 defines the concrete syntax
... converting source into DOM
... and defining values for certain attributes
... other documents would have to define how their things integrate

tantek: extensions work at the DOM or tree model
... instead of the parsing model?

MJS: correct

plh: ...
... maybe it would be worth writing a document somewhere
... saying "these are the use cases for ..."

Hixie: We actually have the use cases for microdata
... but I've never seen that for RDFa

<tantek> Zakim q?

plh: Who is the community who sees them as unrelated
... if we don't tell them "this is what you should use"

Hixie: we have an open bug on making the use of data-* more clear

plh: take those use cases and put them into one document

Hixie: I think the spec does this rather well
... we have an introduction that explains how to use this and (when?)
... In my view, we shouldn't split this out
... there is one thing which needs to be integrated in and that'll help make it clearer

plh: do we have a list of where all the extensions are?

Hixie: this isn't really practical
... there are too many
... and i don't think people will come to the spec looking for this

tantek: I heard three requests from plh
... 1. use cases
... 2. a tutorial, of how to use the different pieces

<Hixie> plh, http://lists.w3.org/Archives/Public/public-html/2009May/0207.html has the list of use cases used for developing microdata

tantek: 3. some sort of documentation iterating all of the extension mechanisms in htm5

plh: ...
... I think we could put some of this in
... a wiki (perhaps)

Hixie: do we have something like this in html4?

plh: no, we don't

<Julian> canvas?

Hixie: i don't think this has been a problem

<annevk> Julian, not an author extension

tantek: when I looked at html4, i had a lot of trouble figuring out what was extensible, and what wasn't
... I ended up writing this up in XMDP

<annevk> Julian, also a bad example, Apple is still regretting doing it unilaterally

tantek: before that, there were very few extensions in html
... it was only after someone took the time to do that, that people started doing that

Hixie: I think it's healthy not to encourage this

plh: If they're going to do it, we want to give them some guidance

[ scribe pauses to roll back to elsewhere ]

Julian: I don't buy the argument that extensibility should not be well documented to make it harder to use it
... people will do it
... see <canvas>

Hixie: well <canvas> happened *way* later
... and I told apple to go to the working group

<Kai> HTML 4 was not extended, because most people didn't really understand it.

tantek: I'm going to stay neutral on this
... it would have helped to have the document i ended up writing
... on the other hand, the process of doing the research
... led me to a far deeper understanding, than had i just read a tutorial
... I'm going to propose to wrap this up
... for people who want such tutorials
... you're welcome to write tutorials, or file change requests

Hixie: ... or file bugs

tantek: ... or just leave material on the side that search engines can find
... I'm hearing no requests for a change request

<Zakim> tross, you wanted to state that guidance helps avoid conflicts with future HTML features

<MikeSmith> scribe: MikeSmith

<tantek> tross: we have had trouble figuring out how to not step on parts of HTML5 with extensions.

tross: ... while also enabling people to produce conformant documents

<scribe> scribe: timeless_mbp

RRSAgent: make minutes

<scribe> scribenick: timeless_mbp

[ proposal for coffee break ]

tantek: I heard plh 's request about use cases
... i'm also going to raise this up
... this has been a source of perma threads on the mailing list
... i think it would be useful to put the use cases somewhere else other than the email archives
... it would be useful to put them, e.g. in a wiki page
... just in the interest of reducing the amount of duplicate traffic on the mailing list

Hixie: I think the use cases are on a wiki page

tantek: I heard that plh is willing to help

<Hixie> plh, http://wiki.whatwg.org/wiki/Microdata_Problem_Descriptions is the wiki page

<Hixie> plh, and http://lists.w3.org/Archives/Public/public-html/2009May/0207.html is the e-mail

Hixie: oh you wanted it for extensions, not just microdata

<annevk> http://wiki.whatwg.org/wiki/New_Vocabularies

annevk: We did have something like this

<myakura> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019681.html that one?

<Hixie> plh, http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21 is the extension mechanism list

tantek: I'm going to ask plh to review that page
... and otherwise, i think this issue is closed

Hixie: plh if you look at all of the urls that were just pasted
... they're all related/derivatives
... the wiki is probably out of date
... feel free to edit the what wg wiki to your heart's content

tantek: other topics?
... it was noted that these are both extensions
... mjs mentioned that html5 allows both attributes and elements
... do both RDFa and microdata add just attributes?

Hixie: that's an incomplete explanation
... RDFa also adds APIs
... one of these relies on something from drag and drop

Julian: I think people are working on a javascript spec for RDFa
... it's not in the spec, but people are working on a proposal

<annevk> (RDFa adds near-infinite attributes)

tantek: any other issues?

<Hixie> what i said above is that microdata has a DOM API, not RDFa

tantek: are we only talking about moving RDFa into a separate spec?

Julian: it's a big time slot

BryanSullivan: it would be good ...
... to have a comparison-tutorial for how these stack up together
... without having to go into them in deep detail

Hixie: it would be really helpful for someone who has not established a public opinion
... to write this

tantek: the source is often accused of bias based on who the source is
... it's a tough problem to compare the three in a way that is objective and seems objective

plh: how stable are all three
... ?

Hixie: microdata and RDFa
... microdata has issues open as to whether it should exist or not
... RDFa has issues as to whether to use namespaces or not
... for microdata, stability depends on when/how we get implementations
... without an implementation in the next six months, then the spec is very fluid

tantek: does anyone want to address stability for RDFa
... technically

Julian: i think there are open questions about edge cases
... i don't anything in the generic syntax

Hixie: there is an open bug about namespaces in RDFa

plh: I don't want someone who might spend time to make a tutorial to waste their time if there's significant potential change

Hixie: ... in microdata, i think the desire is for microdata to cease to exist (?)
... from my point of view, i don't think microdata needs to exist
... RDFa has flaws
... especially namespaces/prefixes

tantek: open issues can be found in the microformats wiki

Julian: i want to mention that there's disagreement as to whether the use of namespaces and prefixes is an actual bug

tantek: is there an actual bug for this?

Hixie: bug 7670

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

MJS: the process for resolving this issue
... will be the same as if this were a bug against the main html5 spec
... the html5+RDFa editor will need to give an initial editor's response
... and if someone cares to raise a complaint, it will go to the issue tracker
... and once it's in the issue tracker, we'll solicit change proposals

Kai: (deutsche telecom)
... I want to make a plug for RDFa
... RDFa is sort of on the upswing
... I don't think one can really say at this point, what's going to happen
... i bet there will be tons of use cases in
... where there will be lots of files
... using this stuff

Hixie: microdata and RDFa are both serializations of RDF
... they fulfill the same use cases
... in exactly the same places where you can have urls in RDFa, you can have urls in microdata
... the exception is per field data types
... and xml-wippls (?)

Kai: i find it difficult for such a relatively small group to foresee what will actually happen

Hixie: just having one of either type will satisfy users

<markbirbeck> @Hixie: I don't like namespaces/prefixes either, but I think they are here for a while to come. However, in the RDFa TF, I am pushing for 'URIs-everywhere' -- i.e., authors don't need to use namespaces if they don't want to. Would that address your issue with RDFa? Or is it really 'all namespaces must go'?

tantek: Kai: i'm going to ask you to review those urls from irc
... and describe the

Kai: I need approval before i could join
... I have a question, have you talked to Ivan Herman?

Julian: I think he's on the RDFa task force

tantek: the specific request was for additional use cases

Kai: i think we could ask Ivan to look for additional use cases

<plh> s/Evan/Ivan/

MikeSmith: was there a dispute as to whether microdata didn't address all the use cases of RDFa
... I think we have massive amounts of use cases

mjs: I think if anyone wants to talk to other communities, they're welcome to
... I think chairs have a lot of work to do

tantek: Kai, request: either you document use cases, or you talk to Ivan and request that he document the use cases on a web page

<Hixie> markbirbeck: imho we should never introduce namespaces to text/html

doug: are we expecting an equal amount of use cases from microdata?

tantek: we already have this for microdata
... I want to Close this Session

<timeless> scribenick: timeless

<hober> (this is several months out-of-date with respect to microdata and rdfa-in-html changes, but) I put together some thoughts on how microdata, microformats, rdf, and rdfa relate: http://edward.oconnor.cx/2009/05/microdata-microformats-and-rdf

tantek: as the queue is empty, and MJS noted time is up

SESSION CLOSED

RRSAgent: make minutes

<dsinger> moving to video in salon B any second

<dsinger> but we're moving to #video, not here

Connectionless Push support in HTML5

<mjs> ScribeNick: mjs

<BryanSullivan> http://dev.w3.org/html5/eventsource/

BS: we're talking about the server-sent events spec

SSE

BS: (brief overview of how SSE works)
... would like to discuss implications of connection-oriented concept
... I work for AT&T - we are interested in push in the OMA
... interested in introducing mechanisms like SMS-push that could be used transparently

<BryanSullivan> http://bkaj.net/w3c/push-html5

annevk, push isn't necessarily tied to SMS

BS: here's some event flows
... this is an example of EventSource over http

<annevk> (the site from bkaj.net is projected)

BS: (more exposition of the diagram)
... let me explain the entities in this picture
... push involves the delivery of events over signaling networks, such as SMS or SIP
... flows involve the client application, and the push client (the UA)
... you need the ability to decode binary push messages
... another entity is the push server, which supports connectionless push, possibly including the push proxy gateway
... the server application runs on a server application, including SSE and possibly Push Access Protocol directly
... does everyone understand the background and objectives?

MJS: is the goal to make this transparent to unmodified EventSource client and server?

BS: yes
... starting with a non-transparent appraoch that works
... uses push server for events delivered outside the EventSource connection
... client application might open EventSorce in some different way

BS the server would be aware of push

BS: the client could make a decision to switch to connectionless
... this would work out of the box today, but some UA changes would be needed

MJS: it seems like when an EventSource goes connectionless it needs to give a unique ID to the server

BS: yes, we'll have to consider these things
... that was the first case
... next case, using a proxy
... this could be mostly transparent
... the UA would have to know how to receive SMS still, but the proxy could hide the push aspects from the server
... (shows SIP example)
... SIP can do MESSAGE for <1300 bytes or INVITE + MSRP for larger messages
... (another flow diagram that involves push service registration)
... in this case you have a negotiation mechanism

IH: when the spec was written originally, the idea was to allow explicitly referencing an SM service with an sms: URL
... but I think this is a better way of doing it
... the middle parts are blackbox equivalent to the spec

BS: the intent is not to put anything into event source, but to provide possible references as a possible deployment option

MJS: need a way to close

BS: in the case of IMA we have a way to deregister
... we like to take small steps
... we would probably do an update for this
... things I'm interested in is how to do routing for multiple applications

<Bryan_Sullivan> scribe: BryanSullivan

<timeless_mbp> ScribeNick: Bryan_Sullivan

LocalStorage

Rob: overall problem is deadlocks between browsers both accessing the same origin's local storage
... one solution: list all the places that will hold the storage mutex
... it's not clear where all those are, etc
... the approach proposed is to spec what does not release the mutex
... there is some debate whether the declaration is a MAY or MUST
... sent to the mailing list a summary of the whatwg proposed solution

<fantasai> HTML Testing Task Force

<fantasai> krisk facilitator

<inserted> scribe: fantasai

kris: Want to hear opinions
... First slide, Why create a test suite?
... Prove that 2 or more impl can be built from the spec
... That's super-important for having an interoperable web
... Example
... SVG
... If we have a set of tests that no one can pass, have to wonder if that section of spec is any good

kris projects a really cool graph

kris: There are some thin slices of red across all browser vendors, happens the same over time
... scary bc you can't use that feature
... he key part is to make sure at least 2 or more browser vendors pass the test
... can see over time, big chunks missing, then filled in
... improvement over time
... When I think of great html5 test suite
... At ten end of the day, it's a software project
... if we don't ship, we don't have a product
... Simple example: 3 browsers, 3 features
... success isn't everyone passing everything
... key thing is at least two browsers can do the same thing
... everyone passing will happen eventually
... after time, browser C is under pressure to fix Test XYZ b/c others have implemented it

Kai: Passing a test means they all adhere to the same criteria, right?

kris: HTML5 fails if we are missing tests for feature XYZ
... spec could be bad
... interop may never exist for XYZ
... Prioritization
... browser test suite space is a complicated space
... prioritization should come from coverage across spec
... some are much more comprehensive than others
... having comprehension is important
... I've looked at some test suites on W3C site, and they aren't comprehensive
... better to have comprehensive than automated
... Don't have much, but I'm interested in building momentum. Interested, ping me
... I need more people, we can do more features, more comprehension, please participate
... We have a mailing list public-html-testsuite@w3.org
... I'll be working on infrastructure stuff
... conference calls if appropriate, etc.
... initially will get consensus on organization of the test suite
... Those are my initial thoughts
... Some things are tought to test from self-description testpoint are pretty doable
... SVG text on a curve moving and then you have to select it

shepazu: In addition to having real conformance tests, I don't think we should underestimate the value of the acid approach
... i think in addition to do implementability tests, I think people should consider some functional subsets of combined atomic tests
... that let authors and browsers really see how things are interacting and make sure corner cases are filled

Adrian: The notion of having tests that result in some kind of score is interesting
... It's clear that where developers value something like that for evaluating some level of conformane
... But choosing an arbitrary subset of features that end up testing corners of thing sdon't actually help interoperability much

Adiran: I don't think we have a problem with tests that show a level of conformance, but it should be clear that's what they're doing

Adrian: Racing to some test turns out not to be very helpful

shepazu: I absolutely agree
... e.g. for SVG I was trying to make some demos, and was having a frustrating time going between rather good implementations
... Sometimes it's a problem with specs, sometimes impl bugs
... What I'm talking about with combinatorial things, e.g. Acid test didn't help with real uses

kris: Acid 1 included a lot of things, didn't have a score, all the pieces might be able to do but can you put them together?

Adrian: Other thing I think is also fair to say, although kris will prolly kill me
... I actually also don't believe that tests designed to highlight bugs that are common across browsers are necessarily a bad thing
... They become a bad thing when people equate them with conformance tests
... It's clear that some of these Acid tests have pushed vendors to fix bugs, but then people use them to evaluate conformance

Kai: I see potential to take the spec to conformance criteria, if you pass tests it eliminates variance across browsers.
... I think it's a nice opportunity to drive consistency

shepazu: There are reasons why W3C hasn't done conformance testing
... To do conf testing, you need far more exhaustive set of tests than for implementability testing
... If we do crowd-sourceing and cooperation among vendors, we may have the resources

<adrianba> fantasai: this is the direction that the css group is moving in

<adrianba> ... hopefully this will produce tools/tests that are useful both to implementers and web developers

shepazu: Kai, it's a great goal to have,

Kai: Who determines what the conformance criteria are

shepazu: This is possibibly a revenue stream for W3C, to help and shepherd the testing activity
... And then have fees for testing to get a gold star or something

Kai: Who determines whether rendering at 0,0 or 10,10 is correct?

fantasai: the spec

kris: ...
... I hear sometimes that the spec is really big, but the test suite is just starting .... I wonder at that

Arron: The tests aren't just for testing implementations to see that they're following the rules.
... They're also testing the spec, to make sure that they aren't saying something insane that can't be implemented

Kai: I think Doug's idea is great, what is the expected result, bring that into conformance criteria (?)

shepazu: What I'd like to see in UI is, "oh, here's a test. Take me to the part of the spec being testsed. Take me from there to all tests for this section."
... If there's a bug in the test, I can talk about it in somme kind of forum.
... make it easy to file a bug on the spec from there
... That's the right way of looking at it
... The idea of ... I'm tired

kris: some suites start out with organization then write tests
... other ones the toc is pulled in afterwards, and the find out they're missing stuff

<Kai> s/,what is the expected result/for any given feature, determine what the expected result is and then

Adrian: We have to be really clear that there's a very big difference in complexity between creating a test suite that's designed to make sure every normative requireement of a spec it's possible to test
... vs test suite designe dto test a UA for compliance to a spec
... Given that we're talking about HTML5, the spec is so huge and hard to test, getting to the point of having the former is going to be really really hard
... Going the huge difference to getting a conformance test, we shouldn't underestimate that
... There's a risk of not ending up with a comprehensive test suite at all if we aim for that

Michael Cooper: I like the idea of getting toward this perfect future, but also be aware that the best is the enemy of the good

Michael: We need spec testing, but design for conformance testing after we exit CR

shepazu: Yes, one thing we don't have w3c, is post-recommendation
... Another step in the process, but have some measure of interop

Arron: Certified recommendation

shepazu: Ok, now, we have fair confidence that this is really implemented widely

<adrianba> fantasai: i don'

<adrianba> ..t think we should ahve a separate step in the process

<adrianba> ... we should have a good way of reporting on implementations

<adrianba> ...like one of those charts - this is where we are at

shepazu: From a product point of view, from a business point of view, having that arbitrary stamp is useful

<MichaelC> Expansion on my comments: Have a perfect future in sight, knowing you won't get all the way there, but at least you know you're on the road towards it (rather than some other road)

kris points to SVG charts. Maybe this shouldn't be a must, because none of the browsers implement it

Adiran: Maybe that's a case for profiling specs

shepazu: ... funds .. certification
... I think oneof the valuable things would be that you would ahave I was just talking to Media Annotations about testing
... They had no idea. They had never seen a w3c test before
... It would be really nice if we had funding for staff and all they did was shepherd groups towards better testability

fantasai: Didn't the QA working group do this?

shepazu: no, they made guidelines, but didn't have a hands-on approach

fantasai: So be more like the i18n wg?

shepazu: Yeah. Promoting testing activity and promote testing culture

kris: All of the w3c specs, there's a lot of consistency. If you see must, it really means must
... But from testing it's all different
... they got to that point and did whatever they needed to do
... You know what, you really need to have a toc
... you need a test for every must

Adrian: There's also a difference between creating guidance which is intended to be prescriptive, e.g. you must do this minimum level of thing to qualify as a test suite
... vs documenting a best practice, "if you follow this process you're more likely to have a more testable spec"
... Guidance that is specific enough to be useful isn't general enough to be applicable broadly

shepazu: That's why having the QA people being hands on

shpazu: coming in and presenting about this document you didn't read :)

kris: I found recently the W3C/QA part with definitions.. how was this hidden?

shepazu: I'd love to promote interop between not just impl but also specifications.

shepauz: e.g. right now CSS, SVG, and XSLFO are all talking about text wrapped to shapes

shepazu: That's great, we need more coordination like that
... One thing that would help with that is having people that wander group to group
... But also extracting definitions. DO I need to define this myself, or extract a definition that someone else wrote

Adrian: Also having someone say "you do realize those guys over there are doing this as well"
... My experience as a consultant is noticing that e.g. you have 3 teams doing this and they don't all know about each other

shepazu: Musts, only things that are a must, once you reach REC status, are royalty-free
... the shoulds aren't
... it's serving this weird dual purpose of interop and IP
... I didn't know this until several months into being a team member
... Nobody knows this

(most of the room didn't know this)

shepazu: One thing atha profile allows, it can enable .. You could have a spec that does the IP problem, and then put shoulds and mays on top of the musts in the spec using a profile

Adrian: Not even about that. For large specs, you can't do all of it in one go. THe advantage of a profile is that it encourages people to do the same things first
... You get interop on that, then move to the next step

shepazu: That's a coordination that encourages cooperation
... People say profiles encourage schizms. In some cases it can. But it also allows coordination

kris: They don't know which things they can go use
... even stuff that is in a draft, no guarantees here, authors want to know that
... This is a must, go use it, and I think that's ok

shepazu: i would love for the validator to say "your code is valid, but these features are not supported by these UAs"
... We could do that if we had a comprehensive testing strategy

kris: It's not that ppl ask if there's a bug or not, but more "is there a reasonable chance of the <video> tag turning into a video element"

Adrian: We've spent a lot of time congratulating ourselves for identifying that testing is important, but how are we actually going to get some tests?
... We now have a testing task force, and apparently, at least the start of a group of people that care about testing
... what's the next step

Mike: get mailing list going, call for participation
... Don't want to really get things going until you get critical mass on the mailing list
... Then once we have discussions going, have some telecons

Adrian: What does momentum look like?

<adrianba> fantasai: here's a goal

<adrianba> ...have 5 tests well documented in a common repository

Arron: And the standard format is important, becaus eotherwise you'll get a lot of tests in a lot of different formats that you can't usefully process

Have 5 tests in a standard format that's well documented in a common publicly-accessible versioning repository

Mike: I dont' remember when it was, I thik 1.5 years ago we tried to start the testing effort. We started a mailing list
... But we had nobody agree to lead the effort. The one biggest thing is having somebody to lead the effort
... Every time I've been involved in somethng like this
... there are some things that should be consensus decisions, and in some cases want executive decisions
... e.g. version control system choice
... The thing I worrya bout most is that it gets bogged down in decisions about what tools to use and even to some degree you need to have decisions on things like, associating metadata with tests
... That allows the system consumign to use that data
... We need a unique id for the test
... so that we can identify it for reporting etc.
... Most people don't care on the format, but somebody needs to take initiative and decide

shepazu: So we got together, with plh, .. talking about omocah hakathon
... We anted to solve some real problems, like set up a repository, set up a way to test across borwsers
... set up common ways to view tests, review tests,

Mike: I just want someone in charge. We have a lot of people wanting to submit test cases

kris: I worry about spending time on infrastructure, but we need the tests
... that's the higher bit than omocha thing.
... If you focus on toolset too much, you have a great tool set but no project shipped

Arron: I think if we have a large set of tests already that are held up by this TF trying to figure out what we need
... just send them
... Then we can look at them and try to blend their formats together to create the standard format
... And then we can in parallel set up the infrastructure

<scribe> ACTION: Arron to start ball rolling on this [recorded in http://www.w3.org/2009/11/05-html-wg2-minutes.html#action03]

<scribe> ACTION: doug to send out instructions on how to get CVS access for dev.w3.org's htmlwg test suite folder [recorded in http://www.w3.org/2009/11/05-html-wg2-minutes.html#action04]

shepazu: Doesn't matter if the CVS repo is temporary and we move to something else later

Adrian: Let's make it a scratch folder, we collect things here for now

shepazu: Give each implementor their own folder, and they organize however they want

Arron: THis is just to collect stuff so that we can review it quickly and decide on what formats we need
... Once we have those formats decided, we can push back on people to update to the common formats

ArroN; and then we can start approving and reviewing those tests and start moving them into a differetn section off the repository that's approved

Adrian: Once we've reviewed and arrived at a format for individual test cases, knowing that will help us figure out what the big picture organization should be
... for the overall test suite
... And determining what that overall structure looks like is a candidate for the executive decision

Arron: ...
... We have this first piece, tackle that, move on to the next piece, move on to the next piece, etc.

kris: Anyone else anything else?

shepazu: Do you know Sylvain Pasche?
... He built on a very similar infrastructure, he's executing tests on all browsers
... it's very elegant
... this is one of the key thigns the test format should eneable
... We like reftests because it enables automation
... The SVG wg spent and additional 2 years of writing tests after writing the spec
... People in wgs are not thinking ahead, thinking that a significant part of their charter time
... will be spent on test

Adrian: Also because the people good at writing specs often arent' the ones writing tests

Arron: That happened with 2.1, we came to the spec and stated writing tests and wound up bringing lots fo issues

people tell stories about why tests are important

minuter takes a break

<Kai> +1

<tantek> concluding session starting in room A

- DRAFT -

HTML WG face to face in Santa Clara, breakout session

05 Nov 2009

Attendees

Contents

RDFa and Microdata

Connectionless Push support in HTML5

SSE

LocalStorage

Summary of Action Items

Scribe.perl diagnostic output