- From: Willabee Wombat <willabeewombat@gmail.com>
- Date: Tue, 16 Oct 2012 21:08:16 +0100
- To: whatwg@lists.whatwg.org
@Alex asked, How should the term "EBacc" (pronounced "E-bacc") be marked up? <dfn title="English Baccalaureate Certificate"><acronym>EBacc</acronym></dfn> On 16 October 2012 20:06, <whatwg-request@lists.whatwg.org> wrote: > Send whatwg mailing list submissions to > whatwg@lists.whatwg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > or, via email, send a message with subject or body 'help' to > whatwg-request@lists.whatwg.org > > You can reach the person managing the list at > whatwg-owner@lists.whatwg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of whatwg digest..." > > When replying to digest messages, please please PLEASE update the subject > line so it isn't the digest subject line. > Today's Topics: > > 1. Re: acronym - Proposal for re-instating (Alex Bishop) > 2. Re: acronym - Proposal for re-instating (Karl Dubost) > 3. Re: A mechanism to improve form autofill (Ilya Sherman) > 4. Re: acronym - Proposal for re-instating (Jukka K. Korpela) > > > ---------- Forwarded message ---------- > From: Alex Bishop <alexbishop@gmail.com> > To: whatwg@lists.whatwg.org > Cc: > Date: Tue, 16 Oct 2012 00:17:29 +0100 > Subject: Re: [whatwg] acronym - Proposal for re-instating > On 15/10/2012 16:40, Willabee Wombat wrote: > >> <acronym> the word is spoken. >> >> <abbr> the abbreviation is spelt out, letter by letter. >> > > How should the term "EBacc" (pronounced "E-bacc") be marked up? > > Alex > > -- > Alex Bishop > alexbishop@gmail.com > > > > ---------- Forwarded message ---------- > From: Karl Dubost <karld@opera.com> > To: Willabee Wombat <willabeewombat@gmail.com> > Cc: whatwg@whatwg.org > Date: Mon, 15 Oct 2012 19:40:29 -0400 > Subject: Re: [whatwg] acronym - Proposal for re-instating > > Le 15 oct. 2012 à 11:40, Willabee Wombat a écrit : > > <acronym> the word is spoken. > > <abbr> the abbreviation is spelt out, letter by letter. > […] > > - Screen readers may make use of them. > > simple definition. > An issue though, (automatic) translation. for example > > <abbr title="United Nations" > lang="en">UN</abbr> > > would have to become in French once translated. > > <acronym title="Organization des Nations Unies" > lang="fr">ONU</acronym> > > -- > Karl Dubost - http://dev.opera.com/ > Developer Relations, Opera Software > > > > > ---------- Forwarded message ---------- > From: Ilya Sherman <isherman@chromium.org> > To: Ian Hickson <ian@hixie.ch> > Cc: whatwg <whatwg@whatwg.org> > Date: Tue, 16 Oct 2012 01:23:26 -0700 > Subject: Re: [whatwg] A mechanism to improve form autofill > Apologies for the delay of this response -- I kept getting sidetracked by > other tasks... > > On Thu, Aug 2, 2012 at 11:42 AM, Ian Hickson <ian@hixie.ch> wrote: > > > On Mon, 23 Jul 2012, Ian Hickson wrote: > > > > > > So we could define the autocomplete="" field's value as follows: [...] > > > > I've now specced this, with some minor changes. > > > > Thanks! I think the spec is quite clear and appropriately detailed. > > My only high-level question is: Why did you choose to drop the proposed > aliases like "city" for "locality" and "province" for "region"? While > "locality" and "region" are probably the most technically correct terms -- > they're certainly the best that I found while researching -- they're not > terms that I'd expect most web developers to be familiar with. I think > including the proposed aliases allows for a more "natural" way to express > many site's forms; and I think that more natural/readable source HTML code > is a Good Thing™. > > Otherwise, a bunch of minor typos and the like, all related to the parsing > algorithm and subsequent sections: > * In step 13.3, "hint set" should be "hint tokens". > * It seems like step 13.6 should precede step 13.5. > * In step 14.3, "hint set" should be "hint tokens". > * In step 14.3, "contact" should be "mode". > * In step 14.4, I think "either is" is more natural than "either be". > * It seems like step 14.6 should precede step 14.5. > * Step 18 is the last mention of the "scope tokens" data in the parsing > algorithm, as well as in the subsequent commentary. What is the intended > function of the scope tokens -- should they be combined with the hint set, > or is there a separate notion of scope that should be invoked by the UA > when parsing this attribute? > * In the paragraph beginning with "Suppose a user agent knows of two phone > numbers", there is a typo: "pefilled" -> "prefilled". > * For terms like "autofill hint set", should the spec use "autocomplete" > rather than "autofill", or is there an intentional distinction being made > here? > > > So instead of <input type=tel autocomplete="work tel"> you would just > > > say <input type=tel autocomplete=work> (and would not be able to say > > > <input type=text autocomplete="work tel">, which would be an inferior > > > user experience when tel is given special behavior, or <input > type=email > > > autocomplete="work tel">, which would be inconsistent). > > > > I'm a little wary about adding more magic here, these attributes are > > already pretty complicated. See the autocomplete section's algorithms and > > let me know if you still think we should do something along those lines. > > If it's something people are willing to implement, I wouldn't want to > > stand in the way; I agree that it has some good side-effects (like making > > it impossible to have certain combinations). > > > > I could also introduce some conformance requirements to make the bogus > > combinations non-conforming; currently I haven't made type=tel > > autocomplete=email non-conforming for instance. > > > > Since the autocomplete type hints are just hints, I think it's ok to leave > this behavior undefined; but I also don't see any problem with making such > mismatches non-conforming, other than that makes the spec even longer/more > verbose. > > On Thu, 26 Jul 2012, Aryeh Gregor wrote: > > > > > > Government-issued ID numbers might be worth adding. In America, social > > > security numbers are sometimes used for this purpose, but are treated > as > > > semi-secret, so you usually don't enter them on web forms. (My American > > > college did use my social security number as an ID number, but not in > > > web forms as far as I remember.) But in Israel, and I assume some > other > > > countries, there are national ID numbers that are considered public > > > info. E.g., my Israeli id number (mispar zehut) is 332752187. It's > > > printed on my checks and things like that, so it's no secret, and since > > > it's guaranteed to exist and be unique, various institutions use it for > > > login instead of or in addition to a username -- my bank, health > > > insurance provider, etc. > > > > I haven't added this yet. > > > > I also haven't added: > > - payment instrument type > > - payment instrument start date > > - payment instrument issue number (for Maestro) > > > > I also haven't removed, as some people suggested, the three cc-name > > subfields. > > > > I'm open to making all these changes, but figured I would get some more > > input on them first, in particular from Ilya who did the research to come > > up with the original set of fields. > > > > I have seen a relatively high number of Chrome bug reports requesting > better handling of (e.g. government) ID numbers. One example: [ > http://code.google.com/p/chromium/issues/detail?id=64433 ]. I think it > would be helpful to add these to the spec; though as subsequent posters > have noted, there's a lot of potential complexity in how these should be > represented. This might fall under the broader class of "identity"-related > fields, which I think merit their own carefully thought out set of tokens. > There was some work done on the beginnings of such a specification -- see > https://wiki.mozilla.org/Identity-inputs -- but my current understanding > is > that this is an area in need of further development. > > The payment instrument type is almost certainly appropriate to add -- it is > included on almost every website that I've encountered that includes > payment card fields. It was an oversight on my part to omit it from the > initial proposal. > > The other two payment instrument field types I haven't encountered on the > Web, as far as I can recall. So, based on my data set accumulated while > working on Chrome Autofill, I'm ok with leaving these out of the spec for > now. However, my experience is biased toward US websites; it's possible > that these fields are more prominent internationally. > > The three cc-name subfields are split out surprisingly often on existing > websites. I was initially opposed to including these in the spec; but that > data in support of them was overwhelming. > > Finally, I have gotten a request to include a field type for bank account > numbers, though I have only seen this info actually requested on a small > handful of extremely prominent (and generally trusted) websites: Amazon, > PayPal, and I think Google Wallet. > > > > ---------- Forwarded message ---------- > From: "Jukka K. Korpela" <jkorpela@cs.tut.fi> > To: whatwg@lists.whatwg.org > Cc: > Date: Tue, 16 Oct 2012 11:32:19 +0300 > Subject: Re: [whatwg] acronym - Proposal for re-instating > 2012-10-16 2:40, Karl Dubost wrote: > > Le 15 oct. 2012 à 11:40, Willabee Wombat a écrit : >> >>> <acronym> the word is spoken. >>> <abbr> the abbreviation is spelt out, letter by letter. >>> >> […] >> >>> - Screen readers may make use of them. >>> >> >> simple definition. >> > > I don't see the definition as simple; it is short, but not simple. > Apparently, <acronym> could not mean just "the word is spoken". We are not > supposed to use it for any word, are we? Instead, the implied idea is > probably that <acronym> indicates that the word has originally been formed > as an abbreviation (of initial letters of words). The question is: why > would it be relevant to indicate such a thing in markup? > > In almost all cases, it would be distracting if a screen reader spoke the > "expansion" of an acronym. Being an acronym means that the expression is > now a word. > > "Abbreviation" is a broad and vague concept, and an abbreviation may be > spoken in different ways: letter by letter, or by pronouncing the > unabbreviated word(s), or as a word (as an acronym). Sometimes even by > pronouncing something completely different, as in reading "e.g." as "for > example". > > An issue though, (automatic) translation. for example >> >> <abbr title="United Nations" >> lang="en">UN</abbr> >> >> would have to become in French once translated. >> >> <acronym title="Organization des Nations Unies" >> lang="fr">ONU</acronym> >> > > And what about e.g. CEN, which might be treated as an acronym, or spoken > using the names of letters (or, in extravagant situations, using the words > from which the abbreviation was once formed)? > > <acronym> is unnecessary and confusing. Even <abbr> is problematic, since > it has often been interpreted so that the title="..." attribute should be > read in its stead - even though the attribute was introduced into HTML as > an advisory title, not as a pronunciation instruction. > > The issue of telling the suggested spoken form of some written text should > be kept separate from any existing markup features. I know that some > software reads title="..." attributes, but it's normally just an option, > and it conflicts with other uses of the attribute. Authors may wish to use > title="..." just to show a visible tooltip, and they do that a lot. > > Yucca > > > > > _______________________________________________ > whatwg mailing list > whatwg@lists.whatwg.org > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > >
Received on Tuesday, 16 October 2012 20:10:12 UTC