<scribe> scribe: JF

CL: asking after status of Editors Draft.

MC: Roy asked me about this. I have some proposed edits, but they have not been provided. Roy is asking about this more fequently
... Roy will add an editorial note covering the other data-dash attributes
... just cleared another large distraction off my desk

<CharlesL> https://raw.githack.com/w3c/personalization-semantics/rewrite-prototype/content/index.html#values

CL: Looking for a review of this. Asked Roy to add a new column
... Asked Roy to ensure taht all of the attributes from @autocomplete also be included here
... So Roy ensured that
... wish to review these today, to ensure we're happy with the final list
... Roy also noted some potential duplicates (Sex/gender)

Becky: We may want to re-think our naming convention (CamelCase verses hyphenation)

CL: Good point

<CharlesL> JF: these tokens are already well established, there should be a real clear migration path, and it should be the same value for machines.

LS: Do we want to move away from CamelCase?

CL: yes, that is the proposal

LS: We may want to look at our other proposals. In data-dash, when you have hyphens, it goes from class to sub-class
... if we want to use hyphens for attributes, then we should follow those same conventions

CL: respectfully disagree. We are using data-dash as a stop-gap, with the desire to move to actual HTML attributes
... if @autocomplete uses address-line-one and we have data-dash=AdressLineOne that doesn't map as easily

+1 to aligning to the @autocomplete values

Becky: agree, we're aiming for HTML, so we should match waht they do, over what the data-dash community is currently doing

<sharon> +1 to align with autocomplete

CL: Understands Lisa's concerns, but given that HTML @autocomplete is already published, we should align with that

LS: Can we review other names and tighten them up?

[agreement]

BEcky: I think they should all be hyphenated, i.e we don't use AutoStarting, we use auto-starting

JF: so, are we saying that *all* attribute values are hyphenated, versus CamelCase?

CL: That would be my preference

JF: discussed about how some attribute values may be missing

CL: yes, noted there was no entry for fax numbers (etc.)
... maybe we should look at these values on the call
... should we use the sort order determined by auto-complete?

Note there is a lot of nameing changes that will need to happen for the Editors Draft

https://www.w3.org/TR/WCAG21/#input-purposes

JF: points to existing values of @autocomplete that were imported into WCAG 2.1 - nameing convention and definitions are already there
... we should stick with that

LS: we need to re-write this table to use hyphens, we should go through the existing list to see if there is anything missing

CL: review existing values. Propose we look at if there are any repeats, then see if any duplicates are aligned to other types

i.e. therre is geneder and sex. @autocomplete has sex, so...

Becky: we should stick with sex

CL: we will remove gender
... looking at email, what is the difference between email purpose and email destination

discussion around scoping. Agree that it needs to be clear without having to read the spec

LS: some confusion about if I want the company to get to me, then my email would also be a destination

CL: but also remember the attribute: destination versus purpose. Given that I think recipient-email makes sense

LS: I think we may get some push-back

CL: Let's start with this, we can always revise later, but for now

BEcky: propose general to specific - email-recipient

RESOLUTION: value for destination to be changed to email-recipient
... move all attribute values from CamelCase to hyphenated values

<LisaSeemanKest_> destination chat Human help or a dialog help function such as a chat bot. No

<LisaSeemanKest_> distraction chat

Discussion of purpose="city" - Becky points out that the existing values use address-level2

LS: not that easy for someone encoding it

CL: agree, but there is i18n issues as well - it seems wrong to have just "city"

even if "city" is clearer here

CL: we could write a note, that shows where city would go - a note that says City: see address-level-2

JF: as authoring guidance, completely agree

CL: good catch Becky, thank-you

RESOLUTION: Add the other address levels (1, 2, 3, 4) from @autocomplete)
... Add authoring note for city (city, see address-level-2)

Becky: why do we have distraction in this list, if the only thing we've approved so far is purpose, action, and destination

CL: yes, we could take this out of the table for now

LS: We should just ignore it for now - less work for Roy

CL: agree, simplification is another one here. I agree, we can ignore thme for now

Becky: we just brought up one under distraction.. do we defer that for now?

RESOLUTION: FOR DISTRACTION, CHANGE VALUE FROM AD TO ADVERTISEMENT

CL: looking at chat

Becky: chat may not always resolve to help - some user may use "chat" with a friend or colleague

LS: what we meant was chat as help

Becky: them maybe we need to change it to chat-help

CL: will continue discussion around chat on next call

<CharlesL> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: CharlesL, stevelee, MichaelC, sharon, Becka11y, LisaSeemanKest, janina
Present: CharlesL stevelee MichaelC sharon Becka11y LisaSeemanKest janina
Regrets: Thaddeus Roy
Found Scribe: JF
Inferring ScribeNick: JF

WARNING: No "Topic:" lines found.

Found Date: 03 Jun 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)