[whatwg] whatwg Digest, Vol 103, Issue 28
Willabee Wombat
willabeewombat at gmail.com
Tue Oct 16 13:08:16 PDT 2012
@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 at lists.whatwg.org> wrote:
> Send whatwg mailing list submissions to
> whatwg at 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 at lists.whatwg.org
>
> You can reach the person managing the list at
> whatwg-owner at 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 at gmail.com>
> To: whatwg at 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 at gmail.com
>
>
>
> ---------- Forwarded message ----------
> From: Karl Dubost <karld at opera.com>
> To: Willabee Wombat <willabeewombat at gmail.com>
> Cc: whatwg at 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 at chromium.org>
> To: Ian Hickson <ian at hixie.ch>
> Cc: whatwg <whatwg at 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 at 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 at cs.tut.fi>
> To: whatwg at 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 at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>
>
More information about the whatwg
mailing list