See also: IRC log
<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...
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
... 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
... 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
... 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).
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
... 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
... 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
... 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> 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> 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> ?? 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> ... 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.
<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
<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.
<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?
<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> 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
<annevk> you guys are done with the <canvas> discussion?
<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
<scribe> ScribeNick: timeless
... 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
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
... 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
... this was regarding vocabulary
tantek: then this wasn't what I understood from yesterday's tag meeting
... 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
... 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
... 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
... 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
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
... 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?
... 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
... 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
... there are too many
... and i don't think people will come to the spec looking for this
tantek: I heard three requests
... 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
... 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
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
... 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
... 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: 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
... RDFa also adds APIs
... one of these relies on something from drag and drop
Julian: I think people are
... 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
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
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
MJS: the process for resolving
... 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
... 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
MikeSmith: was there a dispute as
to whether microdata didn't address all the use cases of
... 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
... 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
RRSAgent: make minutes
<dsinger> moving to video in salon B any second
<dsinger> but we're moving to #video, not here
<mjs> ScribeNick: mjs
BS: we're talking about the server-sent events spec
BS: (brief overview of how SSE
... 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
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
... 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?
... 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
... 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
Rob: overall problem is deadlocks
between browsers both accessing the same origin's local
... 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
... 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
... 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
... 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 firstname.lastname@example.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
... 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
... 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
... 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
... 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 ..
... 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
... 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
... 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
... 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
... 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
... 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
... for the overall test suite
... And determining what that overall structure looks like is a candidate for the executive decision
... 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
... 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
<tantek> concluding session starting in room A
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??/sw/ Succeeded: s/riht/right/ Succeeded: s/html/RDFa/ Succeeded: s/XX/First Public Working Draft/ Succeeded: s/John/Glenn/ Succeeded: s/somethingXX/the Microdata syntax/ Succeeded: s/they want/we want/ Succeeded: s/spot/slot/ Succeeded: s/use cases/open issues/ Succeeded: s/Evan/Ivan/ Succeeded: s/Evan/Ivan/ FAILED: s/Evan/Ivan/ Succeeded: s/push/SMS-push/ Succeeded: s/interested in SMS-push/interested in push/ Succeeded: s/BS/BS:/ Succeeded: s/the/the whatwg/ Succeeded: i/Want to hear/scribe: fantasai Succeeded: s/ahve/have/ Succeeded: s/borwsers/browsers/ Succeeded: s/featuer/feature/ Succeeded: s/shoudl/should/ Succeeded: s/ocvreage/coverage/ Succeeded: s/moementum/momentum/ FAILED: s/,what is the expected result/for any given feature, determine what the expected result is and then/ Succeeded: s/Adiran/Adrian/ Found Scribe: wendy, scribe WARNING: "Scribe: wendy, scribe" command found, but no lines found matching "<wendy, scribe> . . . " Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Found Scribe: timeless Inferring ScribeNick: timeless Found ScribeNick: timeless Found Scribe: MikeSmith Inferring ScribeNick: MikeSmith Found Scribe: timeless_mbp Inferring ScribeNick: timeless_mbp Found ScribeNick: timeless_mbp Found ScribeNick: timeless Found ScribeNick: mjs Found Scribe: BryanSullivan Found ScribeNick: Bryan_Sullivan Found Scribe: fantasai Inferring ScribeNick: fantasai Scribes: wendy, scribe, timeless, MikeSmith, timeless_mbp, BryanSullivan, fantasai ScribeNicks: timeless, MikeSmith, timeless_mbp, mjs, Bryan_Sullivan, fantasai WARNING: No "Present: ... " found! Possibly Present: Adiran Adrian Arron BS Bert BryanSullivan Bryan_Sullivan Dashiva Eliot_Graff Gondo Hixie IH IanH Julian Kai Kangchan Lachy Laura MJS Michael MichaelC Mike MikeSmith Rob SCain TabAtkins adrianba annevk cardona507 cardona507_ cs cyns doug dsinger eric_carlson fantasai fo frankolivier glenn glenng grosmai hober html-wg2 inserted jallan jf joined js kohei kris left manu markbirbeck mm mnot myakura plh prolix richt rubys satoshi sc scribenick sf shelleyp shepauz shepazu shpazu silvia sw tantek timeless timeless_mbp tross wc weinig wendy yofukami You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 05 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/05-html-wg2-minutes.html People with action items: arron cs doug sw[End of scribe.perl diagnostic output]