Meeting minutes
Proposed decision-making process (Lisa) - https://lists.w3.org/Archives/Public/public-personalization-tf/2021Apr/0029.html
<JF> APA Decision Policy: http://
LisaSeemanKest: There was at least one +1 to this process; there's also an APA decision-making process (via Janina).
<LisaSeemanKest> https://
LisaSeemanKest: We need to not conflict with the APA process. That seems focused on CfCs. We can tailor our policy as long as it doesn't conflict with APA's.
LisaSeemanKest: (We can add some things where there is no conflict.)
LisaSeemanKest: I understand that formal decisions go to CfC.
JF: "strives to reach consensus via unanimous agreement" - doesn't _have_ to be unanimous
<JF> W3C Process (Consensus) https://
LisaSeemanKest: We _try_ for unanimity but it's not absolutely required. We try to find something on which there's full consensus though. This is a W3C tenet "art of consensus" (not going for a majority vote).
becky: Could you propose a different wording?
JF: Do we need another decision process? Could we use the W3C (or APA) process?
LisaSeemanKest: Our process is lacking as we've made decisions and re-opened them in the past. We need to agree on e.g. how often we can have the same discussion.
JF: The W3C process allows for re-opening issues as needed.
LisaSeemanKest: The W3C process states that a chair may open an issue if there's new information.
<JF> +1 to better documentation
becky: We don't need a new policy, but we should have a page that records decisions and when they were made (it's fine to re-open if new info/perspective). We need to have a place we can go to find the outcomes and reasoning behind the decisions.
CharlesL: agree with JF and becky. I think the concern was that we're delaying things by rehashing previous issues. Current situation involves a new member trying to understand why certain decisions were made. We do have the matrix and wiki page, but it doesn't document the reasons for the decisions. That's what we need.
CharlesL: When we open up for wide review, we'll need to be ready to provide the answers.
sharon: Shall we have a place on the wiki to capture this info?
LisaSeemanKest: Consensus seems to be for the above; I think we should have a defined process. The first time we decided on this issue was about 5 years ago, and we made a statement to developers that we wouldn't make substantial implementation changes, but we have since made such changes.
LisaSeemanKest: Does anyone want to have a more defined decision policy?
sharon: sounds like we are OK with capturing the information.
becky: +1; we need this as we'll move on and forget about the details in future.
JF: Appreciate LisaSeemanKest's concerns. Implementation issues were raised in the past (which caused me to join). Don't want to slow progress, but also don't want to rush too much.
JF: Current debate is part of the process.
CharlesL: Things may have changed since the last major implementation change (or not) but worth investigating [scribe note: hope this paraphrasing is OK]
<JF> We started with data-* based on TAG feedback, and the goal of a non-prefixed attribute remains
LisaSeemanKest: We comitted to stability but overrode it, which caused implementations to need to be redone.
becky: There may have been adoption concerns that forced our hand somewhat.
<LisaSeemanKest> this is not what i remember, but i dont think it matters. is this conversation going anywere?
CharlesL: We've refined the document considerably over the past few years.
CharlesL: If values are well-defined, it becomes much simpler to change the implementation.
LisaSeemanKest: There is a lot of legacy code, demos, prototypes and all of these things get outdated when things change.
LisaSeemanKest: Suggest we move on to the next item.
sharon: Agree, we need to move this on.
<JF> +1 to better documentation
sharon: Shall we agree to document resolutions on the wiki?
<CharlesL> +1 to documenting that! Yes
+1
Matthew_Atkinson: Thanks to sharon for the research.
Matthew_Atkinson: Also, seems we have to resolve things like conflict resolution before attribute meging (or not) so maybe if we are having problems deciding this, we could look at that first?
<CharlesL> +1
Conflict resolution (John) - https://lists.w3.org/Archives/Public/public-personalization-tf/2021Apr/0032.html
JF: We have three attributes that correspond to three common activities: linking; activating buttons; filling in form fields.
JF: There can be a conflict between the native semantics and the personalization attributes. E.g. a link with role of button is considered by screen readers as a link.
JF: Are we looking to have strong semantics (c.f. ARIA, which overrides native semantics) or be more passive?
JF: Do we say that if you put an action attribute on a link it's non-conforming?
JF: If we merged them we'd not be changing the native semantics; it would have to be passive.
CharlesL: Wasn't thinking anything we do will change the underlying roles.
CharlesL: We're looking at hints.
Matthew_Atkinson: https://
Matthew_Atkinson: was thinking of 8 cases: can we say for each: (1) what does it mean/is it valid? and (2) how do we expect UAs/extensions to act on behalf of our users?
JF: As we're not trying to override, we don't change the element, but we are providing more info about it.
JF: We should have a statement about not changing semantics in our spec.
JF: We had some examples where both action and destination would be used; they feel like edge cases but we want to be sure if we don't need them.
JF: Can we resolve today that our goals is _not_ to change native semantics?
<JF> PLUS ARIA is not supposed to change the UI
LisaSeemanKest: The initial vision was to be part of ARIA and have implied semantics. But we've moved away from this, at least in part, and not everythign we're doing maps to an accessibility API.
LisaSeemanKest: there's still space to say that something should be on a button or a link, and at least give warnings [to developers].
<JF> Proposal: the personalization attributes will not change the native semantic of an element. (+1 to getting this into the W3C validator)
LisaSeemanKest: ...so I think it should be "should" level rather than "must".
LisaSeemanKest: We may need to write a DTD/schema.
<JF> WHAT WG no longer useDTD/Schemas
sharon: Shall we look at Matthew's attribute value examples?
LisaSeemanKest: Some of this seemed to not be from the spec?
<JF> correct, for example the ACTION for help is actually action-"opens-in-page-help"
Matthew_Atkinson: The first set are intended to invovle something that is both an action and a destination. The second set are about something that is only an action. As LisaSeemanKest pointed out, the first set seems invalid per the current spec; will revisit.
JF: Anything that's invalid, per standard UA convention, would simply be ignored.
CharlesL: Understand the questions now; set 1 as discussed isn't correct as we resolved those issues.
CharlesL: If we combined them, then now we don't have that level of validation.
<JF> +1 to Charles
CharlesL: Still some nuance as to whether we combine or keep separate.
Matthew_Atkinson: destination of "signin" (not action) exists. So if it's a login page, we can use a link. What if it's a button that opens a signin form?
<JF> Action="opens-in-page-help"
LisaSeemanKest: If it's a button, might it be the submit button?