See also: IRC log
<trackbot> Date: 14 November 2013
<MichaelC> meeting: IndieUI FtF Day 1
<MichaelC> scribe: jeanne
MC: Do we have a plan to have a plan for doing this? [JC's proposal that the scribe didn't catch]
<janina_> Good point, Kenny. To add to it, gestures for specific actions are different for different devices, but we need web applications to be interoperable across all kinds of devices and interfaces.
JC: This is more commun ity evangelism.
MC: Can we add an action to come back to this?
JC: It's more primary goal and efforts rather than specific parts of the specification
<jcraig> ISSUE: discuss plan for JavaScript library polyfill implementations of IndieUI events, during the transition time when the spec features are unsupported or not fully supported in browsers.
<trackbot> Created ISSUE-13 - Discuss plan for javascript library polyfill implementations of indieui events, during the transition time when the spec features are unsupported or not fully supported in browsers.. Please complete additional details at <http://www.w3.org/WAI/IndieUI/track/issues/13/edit>.
JGW: T his would relate to overall comments that could become more specific later on, more about the order and structure.
<jcraig> ACTION: jcraig to Clarify Goal #3 in IndieUI Events, transition path (including polyfill implementations) are a goal of the working group effort, but not of the spec itself. [recorded in http://www.w3.org/2013/11/14-indie-ui-minutes#action01]
<trackbot> Created ACTION-71 - Clarify goal #3 in indieui events, transition path (including polyfill implementations) are a goal of the working group effort, but not of the spec itself. [on James Craig - due 2013-11-21].
JGW: at least for the first one, and maybe some of the others, it would fall into the category of general requiremetnt or broad features that don't map to specific features of the spec
MC: All of the features depend on these core requirements
... Does anyone else think we have additional goals for hte spec?
JS: No, that's pretty big, that's enough
JC: Next is document skill section
... it's within the purvue of the operating system to say what is a feature of that OS. We aren't specing that the same interaction would have to be the same in each OS.
... we aren't limiting future interfaces.
MC: DO not require specific physical actions to trigger specific Indie-UI events
JC: We can have some strong suggestions here and there.
JS: This is the brilliance of this approach
RS: It allows the platforms to generate the action based on thier user interface.
JC: yes, but it going to be difficult to identify implementations
... mouse events on a platform basis, keyboard events on a platform basis.
... there are patterns of UI on different platforms
JGW: A user agent implementation guide would be one way
... or informative examples or discussion in the specification
... of what events would correspond to Indie UI events. They would be clearly marked as informative.
JC: Like an example of an ESC key.
<Zakim> MichaelC, you wanted to talk about design pattern guide
WAI wants to have an design pattern guide
scribe: perhaps we oculd take that to CG
... but we would not want that entangled with Events
JC: The thing I am talking about is a list of way that various platforms would trigger events in a way that is unique or expected for that platform
... more like a platform implementation guide
JS: I think we are developing vocalbulary.
... it is important stuff and we need to explain it clearly.
MC: I think we should record an issue
JGW: I like the idea that this could be incorporated into a guide that could include ARIA, but I have a question of timing
... could 1- we incorporate into the spec, 2-werite a separate document, or 3- write a separate document that includes larger issues
<jcraig> ISSUE: Consider a platform implementation guide, covering when/how each physical event on various OSes, browser, or platform would map to triggering an IndieUI event (possibly non-normative, since we can't map future implementations, or those where the UI is new enough to not have a commonly recognized interaction pattern for each type of action)
<trackbot> Created ISSUE-14 - Consider a platform implementation guide, covering when/how each physical event on various oses, browser, or platform would map to triggering an indieui event (possibly non-normative, since we can't map future implementations, or those where the ui is new enough to not have a commonly recognized interaction pattern for each type of action). Please complete additional details at
<trackbot> ... <http://www.w3.org/WAI/IndieUI/track/issues/14/edit>.
JGW: what happens when different user agents, or user agents on different platforms that use different commands in different user agents, or the same user agent on different platformns
... this discussion came up at lunch particularly with examples of speech input.
JC: Are you worried about constrains there?
JGW: Unless there is some consistency in actions on different user agents and different platforms, this will be difficult for the users.
JC: This is why polyfills are a critical part of the effort even if they are not part of the spec.
... What do you mean when you say ARIA?
<Zakim> MichaelC, you wanted to say as I now understand the idea of platform implementation guide I think it does apply more specifically to IndieUI but should probably be not normative
MC: This may be part of a WAI design pattern guide. We have an issue about it, and we come to the details when we get to it. It's a question we can get to then.
JGW: I agree with that, and as far as requirements are concerned, the requirement is that we provide non-normative advice on device independent events to Indie-UI events
MC: I don't think it is a requirement
... Are we going to include it in the spec? I thought we were not
RS: Examples in the spec are fine, and I thought we were going to do that, but an overall prescription of behavior
... This is separate from ARIA. If you register something in the DOM that corresponds to an event, @@
MC: I retracked that earlier suggestions
RS: A non-normative mapping of keyboard - touch gestures for Indie UI events.
... it's a separate from the spec
JS: The illustrations will help it
... we had all kinds of efforts to map keyboard and mouse, because platforms were different.
... it's more than keyboard and mouse
JC: We don't want to break backwards compatibility
... by triggering these events from the browser, they aren't going to trigger errors. The author has to register the events.
... scrolling is an example of this
... the scrolling behavior is very smooth, better than can be implemented in javascripts
... the Indie-UI scroll request is blocking the script that is running all the time in the browsers that support that behavior
MC: Structure the events so that they are only triggered if they are registered
<MichaelC> Structure the events such that they are only triggered if the application registers an interest in them, to optimize performance and allow backwards compatibility.
JC: They don't have an default actions -- they only act as a notification to inform tha applecation that the user wants to do something and the app can respond that they will do something
... a click or keypress event @@
... if you want, you can intercept that event and do something with them, but these are request events that won't have anything specifically done with them.
... that's the rest of the backward compatibility section
MC: We might want to have something in a support document about this
JC: Even if the indie-UI event has been triggered, the user agent or platform can acknowledge that the request has been received or not recieved.
... if you trigger an ESC key, if you press it, you have registered for the request.
... if the platform has not recognized the behavior, then they can beep or someother behavior
RS: COuld you pass the key along. there may be an app that is waiting for that request.
JC: Yes, but we shouldn't block physical events.
RS: Do we call that out in the spec?
JC: No, but it would make the browser manufactures more happy.
... We don't want other parts of the page intercepting the ESC key event.
... when the user's point of regard is in a part of the page
RS: This is an issue
MC: 2 requirements:
... provide a way for applications to respond whether or not the request has been handled
JC: the user agent or OS can attempt a fallback behavior
MC: Do not block standard events when listening to Indie-UI events
... I will put an issue in the requirements to go back to this.
<jcraig> ISSUE: When POR is in an element receiving IndieUI Events, should the IndieUI Event "block" standard physical events? e.g. Should dismissrequest prevent the page from receiving Esc keypress while focus is in a dialog that handles dismissrequest
<trackbot> Created ISSUE-15 - When por is in an element receiving indieui events, should the indieui event "block" standard physical events? e.g. should dismissrequest prevent the page from receiving esc keypress while focus is in a dialog that handles dismissrequest. Please complete additional details at <http://www.w3.org/WAI/IndieUI/track/issues/15/edit>.
JGW: I'm looking at the spec. We have done the backward compatibilty part
JC: I have another requirement.
<jcraig> Note: might need a way to "reset" ui-actions on descendant node. e.g. don't prevent fast scrolling on a native scrollview "inside" a custom scrollview.
JC: when POR is in an element whre an event is registered
... don't prevent it from using the native scrolling
... you need a way to reset it.
... it only works the other way
MC: Section 2 - UI Actions
... How much is the structure of Indie UI a response to the requirements, or the way we choose to structure the requirements?
... what are requirements, and what are ways we are simply meeting requirements?
<jcraig> Content attr: <div class="foo bar baz">
<jcraig> DOM attr: myDiv.className = "foo bar baz";
<jcraig> Exact same in HTML and JavaScript
<jcraig> DOMTokenList is new for HTML5 and is defined on the Element.classList property
<jcraig> console.log(myDiv.classList);
<hober> you should probably talk to the tag before propagating classList-like interfaces
<jcraig> > ["foo", "bar", "baz"]
<hober> iirc they don't like it
<hober> (i think it's awesome, personally.)
<jcraig> Oh, T.A.G. not DOM "tag"
<jcraig> hober, please clarify
<hober> sorry, yeah, should have capitalized that
<hober> the TAG, not <tag>
MC: Well, the TAG just made an invitation for groups to approach them
<jcraig> ISSUE: discuss uiactions DOMTokenList with Technical Arch Group
<trackbot> Created ISSUE-16 - Discuss uiactions domtokenlist with technical arch group. Please complete additional details at <http://www.w3.org/WAI/IndieUI/track/issues/16/edit>.
JC: UI action of DOM Elements works in a @@ way.
<jcraig> myDiv.classList.add("bop");
<jcraig> myDiv.classList.contains("bar");
<jcraig> > true
JC: it gives ability to toggle or add it.
<jcraig> Element.uiactions is a DOMTokenList similar to Element.classList
<jcraig> reflects the content attr @ui-actions <div ui-actions="zoom scroll">
<MichaelC> scribe: MichaelC
jgw via jc: applications register at the top of the DOM what events they like
need a way to clarify which specific element they apply to
based on point of regard
so the subsection of the DOM that has UIAction defined
helps define where event triggered
<Zakim> MichaelC, you wanted to say if we need to require a list of values, that might be a requirement, but if that's just a convenient way to structure it, probably no requirement
<jcraig> Requirement re: @ui-actions is related to scoping when to trigger a IndieUI event, when event delegation is (commonly) used on document.body, but the events should only be initiated if point-of-regard is *inside* an element with a matching UI action.
<jcraig> e.g. if "scrollrequest" handler is registers on the body (event delegate), we don't want to prevent native, hardware accelerated, "fast scrolling" from working on the main document. So the event is only "sent" if the point-of-regard is inside element where the the DOM node (or any ancestor) registers both a UI action and the matching event listener.
<jcraig> ACTION: jcraig to add graphic to the spec clarifying relationship of event receiver and event listener, using native scrolling versus custom scrollrequest as as example [recorded in http://www.w3.org/2013/11/14-indie-ui-minutes#action02]
<trackbot> Created ACTION-72 - Add graphic to the spec clarifying relationship of event receiver and event listener, using native scrolling versus custom scrollrequest as as example [on James Craig - due 2013-11-21].
<jeanne> scribe: jeanne
JC: I have drawn up a description
MC: we have a candidate requirement and associated it with Issue 16
JGW: I think we have recorded it and can move forward
JC: For more clarification, read example #3
MC: Possibly more actions after we clarify the structure
... Section 2.2 is the content attribute. We don't need to do more in Section 32
<jcraig> For more clarification of Event Receiver (element with @ui-actions) versus Event Listener (element register for event handling), read Example 3 in section 2.2 https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#h3_uiactions-content-attribute
JC: I think we have covered it.
MC: Section 3
... Do we need to deal with the editorial notes?
JC: Possibly. There may be a requirement with Point of Regard aspects
... each standard javascript event has the Event Listener and the Target
... there are intermediary steps, but they could all be sourced together in the DOM
... in the EventTarget, the listener would be in the text field, and the Listener could be in the top of the document. We may need to clarify where the Point of Regard is and so the screenreader or a reading tracking or speech behavior would know where you are looking at.
MC: I don't think this is a requirement, this is more about how events work.
JC: Events right now are about event at a location. AT doesn't work that way. Speech controlled interfaces don't necessarily work that way.
<jcraig> ISSUE-15?
<trackbot> ISSUE-15 -- When POR is in an element receiving IndieUI events, should the IndieUI event "block" standard physical events? e.g. should dismissrequest prevent the page from receiving Esc keypress while focus is in a dialog that handles dismissrequest -- open
<trackbot> http://www.w3.org/WAI/IndieUI/track/issues/15
<jcraig> ISSUE-14?
<trackbot> ISSUE-14 -- Consider a platform implementation guide, covering when/how each physical event on various OSes, browser, or platform would map to triggering an IndieUI event (possibly non-normative) -- raised
<trackbot> http://www.w3.org/WAI/IndieUI/track/issues/14
<jcraig> ISSUE-13?
<trackbot> ISSUE-13 -- Discuss plan for JavaScript library polyfill implementations of IndieUI events, during the transition time when the spec features are unsupported or not fully supported in browsers. -- raised
<trackbot> http://www.w3.org/WAI/IndieUI/track/issues/13
MC: I think there will be a requirement for how Indie-UI events will fit in the event order
JGW: Is there a requirement for the capacityto ignore the device specific events that trigger a Indie-UI event?
... we need to make sure there is a requirement for the platform to ignore the trigger for the Indie-UI event
JC: We should probably expand issue-15
... add this aspect to issue-15
<jcraig> These events should be asynchronous, but when used in conjunction with keyboard events, we need to define where each IndieUI event fires in the chain of keydown, keyup, and keypress. Probably also need an identifier to associate each event with other related physical events: e.g. this dismissrequest event is associated with the keyboard events keydown, keyup, and keypress of the esc key.
JC: I don't think it is a requirement, it is more of an example
... we need to fit in with other events. I think this covers it for now.
JWG: I don't think it covers it.
MC: Moving on the UI Request Event
... this maybe an implementation of the requirements we have been discussing up until now.
JC: I think it is an implemenation of the requirements we have been discussing so far.
... it could cover the identifier that Jason was discussing earlier
MC: This is an identifier in the case of what Web Apps is publishing.
JS: Or is this an event where events are implemented where Indie-UI events are implementeed?
MC: Must extend UI events unless the Indie-UI events are met directly in UI events.
... Event Types is next section. 3.1.4 Do we need requirements here?
JC: 3.1.4 needs Undo requirements. There are a variety of proposals.
MC: Let's put a placeholder requirement here, in case it is covered elsewhere.
... we want to document requirements for accessibility, so we can link to what covers it, but then we can say that we don't have to meet it in Indie-UI.
JC: Is there a part that is specific to accessibility
jeanne says that UAAG refers to an accessibility need of Undo and Redo.
http://www.w3.org/WAI/UA/UAAG20/#gl-avoid-mistakes
JSp: UAAG considers Undo and Redo an accessibility issue
JC: In either case, it would be tied to a specific user interface, in either case it would not be an accessibility issue.
... it is not necessary in Indie UI because they already handle it in a easy way.
... the user interface already has an Undo function
MC: We need a gigantic requirement -- "Indie UI should support interactions such as Undo when the platform doesn't support it. "
JC: I agree with that suggestion.
<jcraig> in the case of undo/redo IndieUI events, mention already handled by UndoManager
JGW: I agree. List the giant requirement, list all the event actions. There is room to debate them later, associate them with use cases.
... that's a matter of detail, and could be done editorially.
MC: "Indie-UI should support the following functions unless supported by other technologies."
<jcraig> collapse
<jcraig> delete
<jcraig> scroll
<jcraig> toolbarfocus
<jcraig> undo
<jcraig> valuechange
<jcraig> zoom
JC: I've put in the alphabetical list. It doesn't give the context of the subdivision, but it gives you the entire list.
<Ryladog> I see them in chrome
JGW: We will need a sentence or two on each one
MC: I see Nav events that are not on that list.
JC: They are not an event, but are rather a property associated with the event
... the requirements related to those 4 events, they are specific to a UI element, but linear focus and directional focus are not related to a specific element
... so they are not related to the focus order of the particular request
MC: I am moving them to a separate list so they are associated iwth a different candidate requirement.
JC: If you switch windows with command-tab, and command shift tab to move around windows within the applications, like paletters or toolbars in sub windows
... we need a way to move focus that is a non-linear focus
MC: Linear navigation must support navigation for First, previous, next and last. 8 cardinal directions
... palette and toolbar: Most editing apps have a way to move focus to other elements of the document like toolbars, windows and palettes.
... Do they need a way to return to where they were?
JC: That depends on the context of the application.
... once you return to that section, you are centered on that view.
MC: Would it make sense to put a requirement for an option to return to the previous location?
JC: I'm not sure that makes sense on a general scale like this.
JSp: UAWG discussed it and decided not to put the document. they cover it by requiring a return to a point of regard for viewport navigation, but not for toolbars and palettes, because it may not be desirable behavior for that palette.
JS: I often follow a link and when I return, I am at the top of the page.
JGW: Returning the requirements example. If someone is in a text editor, they execute an Indie UI event to go the toolbar. What is the mechanism they would use to get back to where they were working?
... most apps would have specific events to go back to the editing window, and we don't have an Indie-UI event for that.
JC: You and Michael were describing it as a "back to where I was" which doesn't always make sense.
... it wouldn't be a "back to where I was" but it could be a navigate to a bookmark, which could be "back to where I was"
KHS: WHen you say, landmark, are you saying HTML5, and not ARIA.
JC: It could be the HTML5 element or the ARIA role
KHS: I'm not sure that would work for someone with limited mobility. It has to work for everyone, whether or not they use assistive tech.
... has ARIA expanded it's scope? Is the goal for ARIA to support all AT?
JS: Yes, it has always been the intent of ARIA
JC: We are moving away from things that have actual user in terface implementations right now. I know toolbar and palette have ways to do these with keyboard shortcuts.
... I don't know there is a way to do this in web apps.
... navigate toolbars and palettes is mainstream on platforms.
JS: It wouldn't kill me to leave this for 1.x. If we had a short list of accessibility ones we are adding, landmarks would make that list.
JC: We would only be able to handle this with landmarks, but it would be marked "at risk".
MC: Do we want "return to prior point of regard" as a candidate recommendation at risk?
JS: Like in VI and emacs
JC: we could record those examples. Is it always a keyboard or is always a case?
JS: and IDEs.
MC: This requirement does not have consensus yet, and needs to determine if it is keyboard or others as well, It could be pushed to future versions.
JGW: We need to move to the editor window in an editor application. The second priority would be return to a previous point of regard.
JS: it is an interesting list.
... If we support familiar things with familiar actions.
... familiar things are more easily accepted.
<Ryladog> scribe: Ryladog
JS: Are you going to do a talk?
AH: Yes on the 20th if folks need me to do that
JS: Good, please.
AH: It is 4 hours from my house
JS: We met with Web Apps and CSS WG earlier this week. Good outcomes
... Web Apps additional attention from them and an guy from Google is interested in keyboard preferences. And do not oversell privacy
... CSS also went well they will look at our spec feature by feature. Overall they think our approach is good. Tad Adkins has provided some feedback. James ?
JC: Mostly postive and open to the general idea. They thought maybe mediaqueries is not the best approach - his idea is to use a JS query for pairs
... I think we could use a hybrid approach. MQ appraoc has been approved as well as the ket value pairs as well
AH: One big use case is around developing stuff on ePub 3 and eBooks and using metadata.
<andy> http://www.a11ymetadata.org/the-specification/
AH: One spec I have mentioned, schema.org accessibility metadata
... We thought it was final but more new changes have come along. It is close to final. The Access Feature is final.
... Still worjing on AccessMode
... This is the metadata that will be used and we should map to these elements
JS: It would be a win if we could be the mechanism fot ePub 3
AH: Yes. It just happened this week. Preferences that we have got partially map to this. Are we missing some of these. I need to map them.
JS: How much work is this? We want to remail mean and lean
AH: There are political reasons for doing this. What do others think?
MC: Do you mean just documented in our requirements?
AH: They are not all different, in the ePub world that needs preferences for devices. It is not all authored, much is automatic. It is important for us to utilize
... Selection of media, etc, in my view
JC: The Specification section, there is no explanation on how it is intended to be used. Who writes this spec? Can they join our call to explain the use
AH: I should be able to do that. We change categorizations for Media....
JC: Can you explain AccessMode? If we accessed this like a key value pair - give it that info....
AH: This is content metadata
... Preference might be captions, or text to visual
... In general they are pais but they do not all exist. Color dependence - the content depends on info that is coded in color
<MichaelC> scribe: MichaelC
ah: I might be able to do this, but others could also
jc: what actions for this group?
spec doesn't seem ready for group
ah: not quite but not far off
started for AccessForAll3
some of our use cases and requirements map to this, though there has been divergence
<scribe> scribe: Ryladog
JC: This is metadata that describes a content resources?
AH: Yes
JC: Would this be embedded in the webpage?
AH: yes there is a bindimg mecchanism but not CSS
<jcraig> http://www.a11ymetadata.org/the-specification/examples/
CG: I am unsure how
AH: That WAS the suggested binding - I think that has changed
<jcraig> Reminds me of Dublin Core
<jcraig> http://dublincore.org/documents/dc-rdf/
AH: The metadata world, including the IDPF uses HTML5 - the binding mechanism is separtae from the from the idea
JW: I was talking with Gerardo yesterday, we discussed the potetnail relevance of the schema work to IndieUI
... IndieUI could work as a search tool to find schema,org using a query syntx. To automated the restriction ofn the search -wich would
JS: Maybe we should talk with them, but I stray
<jcraig> For example, video search engine could detect via IndieUI preference for captions, and return more relevant results by increasing the relevance of videos that included captions/subtitles.
AH: I think that is right Jason - Gerardo has been working on this for some time, and I am new to it
MC: Gerardo (from Benetech) and Markus
JS: A programmer that works out of San Fran who we added to PF, his name?
... Looking for his name...
<janina_> Bryan Garaventa
AH: Practice Guide for version 6 of this - but the spec is version 7
<jcraig> Oh, yeah, I've met Bryan at some point in the past.
<Zakim> MichaelC, you wanted to say requirements and implementations are a two way street
MC: What requirements might make 2.0 or 3.0 - that might help us to add this in sooner
JS: We could create customers for our spec that way
JW: The questions we have raised is are we going to harmonize our UNandP with the corresponding metadata - that goes to UC Reqs
... That goes with what feature to include in the spec now
... Whether the UC Props should be kept to UA or OS controls in implementation - but James argued that the Props are able in fact to be used by the UA or OS\
... It is now clear that isnt enought to implement the API there must be some mechnaism (outside of IndieUI) with real data from somewhere which might be UAs
MC: Gererdo can come to our call in about 45 minutes
... for about 45 minutes now
snoring stories
JW: what needs to be supported?
AH: It depends on what we take on...supporting...importing somehow
... This is a preference in the data model
... I do not have any good idea of how to get preferences in.
JW: I think we have broad agreement that we didnt want to constrain how the pref were to be used on the UA - the discussion outcome - is using US conformance requirements
... If thatis the case that that help define the scope if all UA provide a mechanism to use the API that we are using
... That seems to fit well. And does help to define the scope of our work if we go with that model
<Zakim> jcraig, you wanted to mention some of the prefs that fit in media queries can be stored in a user style sheet, and system prefs don't need storage
JC: One way is to store the prefiin CSS for a user sytle sheet that fits within MQ. Foe example - Not an override - but a particular font size
... Subtitle etc would fit well in CSS - but others are not they are more OS type controls
... Abstact stuff like auditory over visual - there does not seem to be a way with CSS to define this - a storage format for that would be an implementation detail, and
MC: Gerardo has joined us
JS: Brings Gerardo up to speed
<jcraig> outside the scope of the W3C/
JS: A spec with a customer (schema.org) is better than a spec that is just a good idea
<jcraig> s/that is an implemenetation detail/a storage format for that would be an implementation detail, and outside the scope of the W3C outside the scope of the W3C/
Gerardo: ePub 3 is HTML5 and this - video etc. The challenge is implementers might not implement A11Y features of ePub 3
... Will be approved AccessFeature schema
A11Y.org?
<andy> http://www.a11ymetadata.org/the-specification/
Gerardo: That will be accepted, Access Hazard, Access API (terms for ARIA, most A11Y APIs - maybe Indie UI), Access Controls
... Terms and propertires come from Access for All 24751. AccessMode will not make it in as there is an overlap with some Schema props
... The encoding format properies could be used
... We have started some implementations...use Google Custom search engine
... there is a sample search
<Zakim> jcraig, you wanted to ask about how this metadate is intended to be bound to data, such as a video. and to mention "media feature" is a CSS term, so probably should not use it here
JC: One note, MediaFeature means something in the W3C in CSS - we should not change or reuse it.
Gerardo: We have changed it now to Access?
JC: How is the metadata intended to be bound to real data? How would this be associated to not flash in a video? Embedded?
Gerardo: Micro data is the HTM that wraos around the element
<gcapiel> http://www.a11ymetadata.org/the-specification/examples/#mlk
JC: Embedded with the metadata as well
Gerardo: hasAdaptation will not make it in the spec
JC: Seems to be metadata about the page? but you could confine it to a specific element
<andy> yes - in fact its necessarry
Gerardo: Yes, it should be in a span and not a body element
JC: Inside the video tag?
Gerardo: Correct
... This is not a great example
JC: Consumers would be search engines but maybe UAs as well?
Gerardo: yes, I think so
... example: this page has 3 video but none of them are captioned
AH: There are practices to work out around searches
... when you have multiple features that need metadata
... this is hard but can be done I think
Gerardo: there are problems in some cases with search engines
AH: The UA will addapt the indivuidual objects bo matter the doc type and device
<Zakim> jcraig, you wanted to mention Alex Russell's article, than most of you are going to hate, but deserves a read in the context of this metadata initiative
Gerardo: is gcapiel
<jcraig> http://infrequently.org/2013/11/long-term-web-semantics/
JC: This is Alex Russel who is the author of Dojo, and now works on Chrome
... One conclusion he makes the role of SEs is not to parse metadata
... He takes a hard stance against linked data
... He asserts most web authors won't add linked metadata, so it is more useful for search engines to resolving their bugs in "decoding the soup" than to expect authors to include immaculate metadata in web pages. - he may have some valid points here
<MichaelC> ack
JW: That arguement that Alex makes is problematic - one could say that about markup in generral
... We need to solve the underlying recognition problems - for now that appears to be authors.
... My undertsnaing related to UC spe c could supply a NandP profile that would supplement hat the user provides a search query
... Needs and Prefs on one side Content on the other
AH: Good Jason. I have been around metadata about 12 years now. That is a common question. The future is not to use metadata.
... We are still in the old world. This is scaffolding, a way to go until we get to better automated processes
... I work on preference - b/c the metadata scaffold for now - but in the future we will continue to define the prefrences
JC: The use case searching for video that Jason brought up - that idea is grand. If a video site knows about its captions and can sprinkle in that microdata, great. It may make for better search results.
... I just wanted to point out the article, because I see a lot of the same ideas get recycled in the groups working on large-scale metadata initiatives.
Gerardo: the eaasier we make it for authors the better. Plugin for Wordpress - let have the plugin insert the metadata
JS: Thank you to Gerardo, for coming. And your ideas
Gerardo: Brian G is a wizkid with A11Y for dynamic apps such as jQuery - as a developer he would be a good person to get info from
... I will read up on IndeUI only a little bit
JC: Please reads the User Context spec
... example, Check to see if an author wants captions
JS: We are trying for a first draft soonish and finding implementors
... If you have something we can start talking ti UAs about that would be great
Gerardo: We will add this to our agenda
AH: We need to bring it up to 7 and a Best Practice Guide based on version 7
Gerardo: We need to update our guide, they should map to the IndieUI and A11Y metadata
JC: we are considering some of the UC fit into CSS, but other do not fit well. How were you thinking that a search engine would get information out for limited seach results
... How do we let the US know about it, for Search engines to find it
... exampke, Simplified Interface - how would that best be specified?
... Now or 2.0
Gerardo: that may be a privacy issue
JC: we have a good story for provacy I think
Gerardo: query string will expose your preferences
JC: That is a second step removed that Seach engines could abstract it
AH: It is not just the search case, it is the adaptaion on the delivery device and we need to think about how that get s in there. It is not just the browser. And goes back to conformance for UAs
JW: I agree with Andy. how does the AU populate the prefs? There should be requirement on the UA - we have not started the details of that discussion
... How will UAa populate the profiles?
JS: Break until 4pm, I am going o HTML for 10 or 15 minutes
JC: What is the HTML topic?
JS: Bugs
BREAK
<MichaelC> Copying my notes from Events discussion this morning
<MichaelC> Events Requirements
<MichaelC> 1.2 Goals
<MichaelC> Provide an API layer to define user intended events that is agnostic of the specific input methodology and independent of a user's particular platform, hardware, locale, and preferences.
<MichaelC> Allow the API to support user commands without requiring specific physical events.
<MichaelC> 1.3 Scope
<MichaelC> Do not require specific physical user interactions (keyboard combinations, gestures, speech, etc.) to trigger particular IndieUI events.
<MichaelC> 1.5 Backwards Compatibility
<MichaelC> Structure the events such that they are only triggered if the application registers an interest in them, to optimize performance and allow backwards compatibility.
<MichaelC> Provide a way for applications to communicate that a given event request was or was not handled so the host OS or UA can attempt fallback behaviour.
<MichaelC> Do not block standard events when listening for IndieUI events. ISSUE-15 may impact this.
<MichaelC> Provide a way to "reset" ui-actions on descendant node. ISSUE-15 may impact this.
<MichaelC> 2. UI Actions
<MichaelC> Allow event delegation without affecting performance and scoping of events. ISSUE-16 impacts this.
<MichaelC> <possibly other requirements after we clarify implications of this structure>
<MichaelC> 3. UI Request Events
<MichaelC> There will be a requirement for how IndieUI events fit in with the order of other events ISSUE-15
<MichaelC> Might need a requirement to be able to associate an IndieUI event with other related physical events ISSUE-15
<MichaelC> 3.1 UIRequestEvent
<MichaelC> IndieUI Events must extend UIEvents unless the IndieUI requirements are met directly in UI Events.
<MichaelC> IndieUI must support the following functions unless supported by other technologies: undo, redo, expand, collapse, dismiss, delete, move, pan, rotation, scroll, valuechange, zoom
<MichaelC> Support linear navigation for first, previous, next, and last.
<MichaelC> Support directional navigation for (8 cardinal direction).
<MichaelC> Provide a mechanism for users to move focus non-linearly to other sections of the document such as toolbar, palette, and windows.
<MichaelC> Provide a way to navigate amongst landmark regions. This may be at risk in 1.0 and could be pushed to future version. Might be a11y specific.
<MichaelC> Provide a way for users to return to their previous point of regard, like emacs and vid and IDEs support. This does not have consensus yet. Need to determine if it is just keyboard or others as well. Could be pushed to future version. Seems to have general use cases.