<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.)[End of scribe.perl diagnostic output]