Re: [whatwg] Supporting more address levels in autocomplete
On 22/02/2014 04:05, Ian Hickson wrote: The post office will deal with all kinds of stuff, sure. But Web forms only have to accept the formal address format, which in the UK only ever has a street, a locality (sometimes), a post town, and a post code. That’s all Royal Mail has to deal with, sure (with the possible addition of a named building on a street, which almost always seems to merit its own line), but don’t forget that there can be additional lines above that for flat numbers, office departments, buildings on a site, etc. In my experience, it’s not uncommon for business or university hall of residence addresses to have two or three lines before the street part. Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] URL: file URL C| quirk
On 08/07/2013 23:25, Peter Kasting wrote: On Thu, Jul 4, 2013 at 5:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Both Gecko and Chromium have a quirk with C| and similar patterns (drive letter followed by |). They treat it similarly to C:. However, Internet Explorer does not do this. Should we remove this quirk? I searched for file URL drive letter pipe on Google and found a variety of comments about programs/libraries that output URLs with a pipe instead of a colon after a drive letter name. It sounds like there are likely compatibility issues connected to this quirk. I have a recollection of early Netscape versions displaying local file paths in the Location bar as something like file:///c|/windows/canyon.mid. Performing some code archaeology at https://mxr.mozilla.org/classic/source/cmd/winfe/fegui.cpp#2531 (note line 2359) suggests that I was not hallucinating (there are other places in that file where ':' and '|' are treated more or less equivalently in file: URLs). I imagine that it’s an early Netscape implementation detail that escaped into the wild. Given that I can still remember pipes in file URLs 15+ years later, I would not be surprised if other people rely on this working. Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Why do we have input type='month' and input type='week'?
On 30/01/2013 20:55, Mounir Lamouri wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Credit card expiry date?
Alex
--
Alex Bishop
alexbis...@gmail.com
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 alexbis...@gmail.com
Re: [whatwg] Suggest making dt and dd valid in ol
On 19/07/2012 08:04, Ian Yang wrote: Since the *optional *use of li in dl could solve many problems, may we have li being valid in dl? Probably not, as it has similar drawbacks as the proposed di element: http://wiki.whatwg.org/wiki/FAQ#HTML_should_group_.3Cdt.3Es_and_.3Cdd.3Es_together_in_.3Cdi.3Es.21 Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Editorial: ASCII case-insensitive string comparison
On 12/05/2012 13:47, Øistein E. Andersen wrote: When I read Anne van Kesteren's Encoding specification recently, I came across the following definition, borrowed from HTML5: Comparing two strings in an ASCII case-insensitive manner means comparing them exactly, code point for code point, except that the characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also match. The construction ‘are considered to also match’ seems awkward here since the intended meaning is clearly not that the characters match in addition to doing something else like in ‘I don’t just want you to laugh but to also sing along’ or ‘our face/tongue system allow[s] us to talk and eat—but also to sing and act’. Sure they do. They match in addition to the usual matching rules (i.e. comparing them exactly, code point for code point). A pair of characters match if they have the same code point. A pair of characters also match if one is an ASCII upper-case character and the other is the equivalent ASCII lower-case character (or vice-versa). Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] html, head and body tag
On 19/02/2012 00:24, Keefe Tang wrote: Thehtml,head andbody tag has been optional since HTML4 (http://www.w3.org/TR/html4/struct/global.html) and I was wondering if it is still the case with HTML5 since it no longer specify that the tags are optional on the current HTML5 spec page (http://www.w3.org/TR/html5/semantics.html#the-html-element). The html, head and body start and end tags can be omitted in certain circumstances. See http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#optional-tags for details. Alex -- Alex Bishop alexbis...@gmail.com
[whatwg] Any content inside wbr elements must not be considered part of the surrounding text
The definition of the wbr element says: Any content inside wbr elements must not be considered part of the surrounding text. How's that work? The wbr element is a void element; it can't have any content. Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Timed tracks: feedback compendium
On 03/01/2011 15:57, Philip Jägenstedt wrote: There was also some discussion about metadata. Language is sometimes necessary for the font engine to pick the right glyph. Could you elaborate on this? My assumption was that we'd just use CSS, which doesn't rely on language for this. It's not in any spec that I'm aware of, but some browsers (including Opera) pick different glyphs depending on the language of the text, which really helps when rendering CJK when you have several CJK fonts on the system. Browsers will already know the language from track srclang, so this would be for external players. Firefox too. If you visit http://people.mozilla.org/~jdaggett/webfonts/serbianglyphs.html in Firefox 4, the text explicitly marked-up as being Serbian Cyrillic (using the lang=sr-Cyrl attribute) uses some different glyphs to the text with no language metadata. Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Make f...@bar.com, a valid email address list
On 23/10/2010 22:16, Garrett Smith wrote:
On 10/22/10, Anne van Kesteren ann...@opera.com wrote:
On Fri, 22 Oct 2010 19:44:42 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/22/10 1:25 PM, Garrett Smith wrote:
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(,);
That depends on what meaning of email address is used here. Is:
Zbarsky, Boris bzbar...@mit.edu
a valid email address?
Not per HTML5.
Link:
http://www.w3.org/TR/2010/WD-html-markup-20101019/input.email.html
Quote:
A single e-mail address.
Any string that matches the following [ABNF] production:
1*( atext / . ) @ ldh-str 1*( . ldh-str )
…where atext is as defined in [RFC 5322], and ldh-str is as
defined in [RFC 1034].
Definition of atext from RFC 5322:
atext = ALPHA / DIGIT /; Printable US-ASCII
! / # /; characters not including
$ / % /; specials. Used for atoms.
/ ' /
* / + /
- / / /
= / ? /
^ / _ /
` / { /
| / } /
~
ALPHA and DIGIT are themselves defined in RFC 5234 to be the letters A
to Z (upper-case or lower-case) and the digits 0 to 9 respectively.
Definition of ldh-str from RFC 1034:
ldh-str ::= let-dig-hyp | let-dig-hyp ldh-str
let-dig-hyp ::= let-dig | -
let-dig ::= letter | digit
letter ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
digit ::= any one of the ten digits 0 through 9
In other words, the letters A to Z (upper-case or lower-case), the
digits 0 to 9 and the hyphen.
Therefore
Zbarsky, Boris bzbar...@mit.edu
is not a valid email address because the portion before the @ contains
characters that are not atext (namely, the quotation marks, the comma,
the spaces and the left angle bracket) or dots, and the portion after
the @ contains characters that are not ldh-str or dots (namely, the
right angle bracket).
bzbar...@mit.edu is, however, a valid email address.
Alex
--
Alex Bishop
alexbis...@gmail.com
Re: [whatwg] Consensus on video element (scriptable) Full-Screen
On 21/09/2010 20:22, Shiv Kumar wrote: Now in order for anyone to be able to provide their own skin/player, we’ll need to provide a scriptable way to switch the video element to full screen and out including events to support the same. There have been previous discussions about allowing scripts to request that arbitrary content (including video elements) fill the full screen. Here's one proposal: https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI Alex -- Alex Bishop alexbis...@gmail.com
[whatwg] Processing image map area elements in the Circle state (section 4.8.13.2)
In the processing model for image maps (section 4.8.13.2), step 8 of the processing instructions for area elements says that if the shape attribute is in the Circle state: Let x be the first number in coords, y be the second number, and r be the third number. The shape is a circle whose center is x CSS pixels from the left edge of the image and x CSS pixels from the top edge of the image, and whose radius is r pixels. Surely x CSS pixels from the top edge of the image should read y CSS pixels from the top edge of the image? Alex -- Alex Bishop alexbis...@gmail.com
[whatwg] The StyleSheet object (section 4.2.7)
There's a few parts of the specification of the StyleSheet object defined in section 4.2.7 that are unclear to me. The location (href DOM attribute) For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty string if that fails. For style elements, there is no location. If there is no location, does that mean the attribute is null? Should that be explicitly stated? The intended destination media for style information (media DOM attribute) The media must be the same as the value of the element's media content attribute. If the element's media content attribute is omitted, what should the value of the attribute be? Should it be all (which section 4.2.6 defines as the default if the media content attribute is omitted)? Null? The empty string (à la DOM reflection)? In any case, the definition above seems to conflict with the definition of the media attribute in the CSS Object Model specification at http://dev.w3.org/csswg/cssom/#stylesheet, which requires that the attribute returns a MediaList. The style sheet title (title DOM attribute) The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty value. If the attribute is absent or its value is the empty string, then the style sheet does not have a title. The title is used for defining alternative style sheet sets. Again, if there is no title, does that mean the attribute is null? Alex -- Alex Bishop alexbis...@gmail.com
[whatwg] Language codes: RFC 3066 versus RFC 4646
In several places in HTML5 (specifically, sections 3.3.3.3, 4.2.5.3 and 5.11.1), the specification states that certain attribute values must be valid RFC 3066 language codes. However, RFC 3066 was replaced by RFC 4646 (and RFC 4647) in September 2006. Is there a reason that HTML5 refers to the older standard or is this just an oversight? Alex -- Alex Bishop alexbis...@gmail.com
