Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote: The trailing dot actually had meaning, but in my periodic testing most commerce websites didn't handle it well. It didn't help that browsers never favored adding it. On a somewhat (user) hostile network, http://discover.com/ might go to http://discover.com.example.com/ this probably isn't what the user wanted (it certainly wasn't what I wanted when I tested), but using http://discover.com./ got unfortunate redirects or unhappy responses from the remote server. That's all relevant for trailing dots on hostnames; I think the context here is trailing dots on IP addresses, which I don't think have the same meaning, since force this to be treated as a FQDN doesn't really mean anything when you're not doing DNS resolution. I believe for non-IP hostnames, Chrome should be respecting the trailing dot. For IPs, losing the trailing dot seems OK to me. PK
Re: [whatwg] IPv4 parsing
The trailing dot actually had meaning, but in my periodic testing most commerce websites didn't handle it well. It didn't help that browsers never favored adding it. On a somewhat (user) hostile network, http://discover.com/ might go to http://discover.com.example.com/ this probably isn't what the user wanted (it certainly wasn't what I wanted when I tested), but using http://discover.com./ got unfortunate redirects or unhappy responses from the remote server. These days with HSTS, mobile phones, and hopefully some future ubiquitous VPN, we can ignore the risks of hostile local DNS/DHCP servers. Also fun and probably worth documenting is how http://127.1/ and http://127.2.1/ are parsed. I doubt the average developer knows (unless they specifically deal with low level networking). You have http://0.0.0.66/ that's not a match for your example... On Jun 22, 2015 12:52 PM, Anne van Kesteren ann...@annevk.nl wrote: I've done some research into how Chrome parses IPv4 addresses to see if that's worth standardizing. Most browsers do not have special parsing rules for IPv4 vs domain names. That is, they pass the domain name to the network layer and let that figure out what should happen. Typically, that results in a URL such as http://0x42。0./ (note the 。 and trailing .) to end up connecting to IPv4 address 66.0.0.0 with 0x42.0. in the Host header. The resulted parsed URL will be http://0x42.0./. Chrome will instead have 66.0.0.0 in the Host header and its parsed URL will have that value too. That means you lose functionality Host-header wise, but it is more predictable (and no longer depends on the networking stack) where you connect to. That seems somewhat more secure, since it might not be entirely obvious that e.g. http://0x42./ is not a domain name. If the resulting URL is http://0.0.0.66/ it's very clear what is going on. And we don't depend on whatever the OS networking library does. Now, is that what we want? Is losing the trailing dot acceptable? -- https://annevankesteren.nl/
Re: [whatwg] Input and spell check/keyboard settings
Florian Rivoal wrote: If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. The principle of least surprise argues against this. Most mobile phones support many more languages and keyboard layouts than their users know how to use. Users typically configure layouts for which they have a use, and they learn how to use then and switch between them. Desktop operating systems include optional keyboard shortcuts for switching languages. Most mobile devices include a globe or the ability to press and hold the space bar to switch. Some keyboards support multilingual input. Some are even smart enough to perform spell checking against multiple languages. But if I've only configured Hebrew and English and a web page has an input with lang=ru or manages to specify an IME which is totally foreign to me, I'm going to panic. (For the prototypical user anyway, I'm odd in that I've probably used the input method before.) Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). On multi user desktops, the existence of IME support doesn't indicate that all users of the computer are remotely comfortable with each IME. Not sure if any spec change is needed for that. Keyboard layout and IME should be opaque to browser content, so this sort of thing should be something where browser vendors are free to experiment and discover that it's just not worth it (because language tagging is wrong more often than it's right).
Re: [whatwg] Site-Wide Heading Element
On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote: (This is my first post here, so I’m not sure about appropriate protocols). HTML5 adds more power to the heading elements, which is a good thing. However, there appears to be no recommended element for marking up a site-wide banner title. Presumably, the correct element is h1 for the banner heading, but this may be at odds with the notion that h1 should describe the specific page. The banner title would be expected to be the same for most, if not all, pages, while the h1 might be expected to be different for each page. While we should not pay too much heed to the whims of search engines, there is the notion that varying the h1 in pages is good for SEO. For this reason many site owners and developers are reluctant to use the main h1 as a banner title. As far as I am aware, there is no suitable HTML(5) element for a site-wide heading. I would like to see the introduction of such an element. Here are some suggestions: * The purpose of the element is to provide a semantically appropriate container for a site-wide title. * From a behavioural point of view, it would be similar to an h1 element. That is, a block element with mostly text. * There would be no other special default appearance, much like a paragraph. CSS can handle the rest. * There should only be one such element on a page, in the body element. It may be nested inside another suitable element, such as a header. I have no strong opinion on the name of the element. Some suggestions are: title, banner, name, sitename, site, elementwithoutanyothername. -- Mark Simon Manngo Net Pty Ltd mobile:0411 246 672 email:m...@manngo.net mailto:m...@comparity.net web:http://www.manngo.net Resume:http://mark.manngo.net What would be the value of such an element? There is an aria-role for banner I believe..
Re: [whatwg] Last Call: draft-ietf-appsawg-multipart-form-data-08.txt (Returning Values from Forms: multipart/form-data) to Proposed Standard
http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/masinter/multipart-form-data/master/multipart-form-data.xmlmodeAsFormat=html/asciitype=ascii Encoding considerations:Common use is BINARY. In limited use (or transports that restrict the encoding to 7BIT or 8BIT each part is encoded separately using Content-Transfer-EncodingSection http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/masinter/multipart-form-data/master/multipart-form-data.xmlmodeAsFormat=html/asciitype=ascii#cte 4.8 http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/masinter/multipart-form-data/master/multipart-form-data.xmlmodeAsFormat=html/asciitype=ascii#cte . You have an unclosed parenthesis here. Larry Masinter wrote: please note instructions for substantive comments: mail to i...@ietf.org w/same initial subject line
Re: [whatwg] Input and spell check/keyboard settings
On 24 Jun 2015, at 13:07, timeless timel...@gmail.com wrote: Florian Rivoal wrote: If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. The principle of least surprise argues against this. Most mobile phones support many more languages and keyboard layouts than their users know how to use. Users typically configure layouts for which they have a use, and they learn how to use then and switch between them. I meant you would only be switched between the ones the user has activated and can manually switch between. Desktop operating systems include optional keyboard shortcuts for switching languages. Most mobile devices include a globe or the ability to press and hold the space bar to switch. Some keyboards support multilingual input. Some are even smart enough to perform spell checking against multiple languages. But if I've only configured Hebrew and English and a web page has an input with lang=ru or manages to specify an IME which is totally foreign to me, I'm going to panic. (For the prototypical user anyway, I'm odd in that I've probably used the input method before.) In my case, it's French, English, Japanese and Chinese. I wouldn't be too happy to see a Russian keyboard pop up either. But there is a set of keyboards I'm happy to use and would prefer to have the most appropriate one shown. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). On multi user desktops, the existence of IME support doesn't indicate that all users of the computer are remotely comfortable with each IME. In theory, you're right, but in practice, IME only tent to be installed/activated on computers of countries where needing one is normal. There can certainly be some that don't fix expectations, but that's the exception rather than the norm. Not sure if any spec change is needed for that. Keyboard layout and IME should be opaque to browser content, so this sort of thing should be something where browser vendors are free to experiment and discover that it's just not worth it (because language tagging is wrong more often than it's right). Chicken and egg. Language tagging is often wrong because the consequences of getting it wrong are limited. The more it is used, the more important it will be to get right, and so authors would pay more attention. I don't think that we need to do much more than point out that the UA should display the most appropriate input system given the information it has about the content and the user's expectation. It could be reasonable to spec that if the user explicitely sets the language of the spell checker, or of the virtual keyboard, or similar, then the UA should update the lang attribute of the focused element accordingly. - Florian
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 1:50 PM, Tim Streater t...@clothears.org.uk wrote: On 24 Jun 2015 at 20:15, Peter Kasting pkast...@google.com wrote: 1.66 = 1.0.0.66 1.256 = 1.0.1.0 1.2.66 = 1.2.0.66 1.256.66 = invalid This makes no sense at all. https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02#section-2.1.1 explains why Quoth the text Meanwhile, a very popular implementation of IP networking went off in its own direction. 4.2BSD introduced a function inet_aton(), whose job was to interpret character strings as IP addresses. It interpreted both of the syntaxes mentioned in [MTP] (see above): a single number giving the entire 32-bit address, and dot-separated octet values. It also interpreted two intermediate syntaxes: octet- dot-octet-dot-16bits, intended for class B addresses, and octet- dot-24bits, intended for class A addresses. It also allowed some flexibility in how the individual numeric parts were specified: it allowed octal and hexadecimal in addition to decimal, distinguishing these radices by using the C language syntax involving a prefix 0 or 0x, and allowed the numbers to be arbitrarily long. The 4.2BSD inet_aton() has been widely copied and imitated, and so is a de facto standard for the textual representation of IPv4 addresses. Nevertheless, these alternative syntaxes have now fallen out of use (if they ever had significant use). The only practical use that they now see is for deliberate obfuscation of addresses: giving an IPv4 address as a single 32-bit decimal number is favoured among people wishing to conceal the true location that is encoded in a URL. All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable.
Re: [whatwg] A mask= advisory flag for link rel=icon
On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak m...@apple.com wrote: To close the loop on this, we will change to link rel=mask-icon href=whatever.svg color=#aabbcc. We like the idea of determining the color from the SVG, but we won't be able to implement in time for this cycle, and having an explicit color override seems useful. So for now we'll implement explicit color and we'll consider automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Sounds acceptable to me. What's the grammar of color=''? Just hex, or full CSS color? (Either is fine with me.) ~TJ
Re: [whatwg] Site-Wide Heading Element
On 24/06/2015 9:08 pm, Jonathan Zuckerman wrote: On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote: (This is my first post here, so I’m not sure about appropriate protocols). HTML5 adds more power to the heading elements, which is a good thing. However, there appears to be no recommended element for marking up a site-wide banner title. Presumably, the correct element is h1 for the banner heading, but this may be at odds with the notion that h1 should describe the specific page. The banner title would be expected to be the same for most, if not all, pages, while the h1 might be expected to be different for each page. While we should not pay too much heed to the whims of search engines, there is the notion that varying the h1 in pages is good for SEO. For this reason many site owners and developers are reluctant to use the main h1 as a banner title. As far as I am aware, there is no suitable HTML(5) element for a site-wide heading. I would like to see the introduction of such an element. Here are some suggestions: * The purpose of the element is to provide a semantically appropriate container for a site-wide title. * From a behavioural point of view, it would be similar to an h1 element. That is, a block element with mostly text. * There would be no other special default appearance, much like a paragraph. CSS can handle the rest. * There should only be one such element on a page, in the body element. It may be nested inside another suitable element, such as a header. I have no strong opinion on the name of the element. Some suggestions are: title, banner, name, sitename, site, elementwithoutanyothername. -- Mark Simon Manngo Net Pty Ltd mobile:0411 246 672 email:m...@manngo.net mailto:m...@comparity.net web:http://www.manngo.net Resume:http://mark.manngo.net What would be the value of such an element? There is an aria-role for banner I believe.. There is also an aria-role for “article” but this doesn’t invalidate HTML5’s article element. Section 1.4 makes it clear that it is preferable for the host language to do the job itself. In any case, the “banner” role would be more suited to something like a div, which is what the header element is doing. The proposed element would be more like h1. How about h0? That would be more in the pattern of things. -- Mark Simon
Re: [whatwg] Site-Wide Heading Element
On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote:
Presumably, the correct element is h1 for the banner heading, but this
may be at odds with the notion that h1 should describe the specific
page.
The banner title would be expected to be the same for most, if not all,
pages, while the h1 might be expected to be different for each page.
While we should not pay too much heed to the whims of search engines,
there is the notion that varying the h1 in pages is good for SEO. For
this reason many site owners and developers are reluctant to use the main
h1 as a banner title.
As far as I am aware, there is no suitable HTML(5) element for a
site-wide heading. I would like to see the introduction of such an
element. Here are some suggestions:
* The purpose of the element is to provide a semantically appropriate
container for a site-wide title.
* From a behavioural point of view, it would be similar to an h1
element. That is, a block element with mostly text.
* There would be no other special default appearance, much like a
paragraph. CSS can handle the rest.
* There should only be one such element on a page, in the body
element. It may be nested inside another suitable element, such as a
header.
On Jun 24, 2015, at 7:08, Jonathan Zuckerman j.zucker...@gmail.com
wrote:
What would be the value of such an element? There is an aria-role for
banner I believe..
On Jun 24, 2015, at 5:03, Mark Simon m...@manngo.net wrote:
There is also an aria-role for “article” but this doesn’t invalidate
HTML5’s article element. Section 1.4 makes it clear that it is
preferable for the host language to do the job itself.
In any case, the “banner” role would be more suited to something like a
div, which is what the header element is doing. The proposed element
would be more like h1.
How about h0? That would be more in the pattern of things.
When I build a website that is to have more than one page, and I want the
banner to be the same across all pages, I use the header element with a
javascript file embedded inside, like this:
header id=banner
script src=scripts/header.js type=text/javascript/script
/header
and the javascript file looks like this:
document.write('\
hgroup class=myHeader\
h1The Site Name/h1\
h2Site Tagline/h2\
/hgroup\
');
This way the h1 element is still free to use as the main body heading in
the document itself.
The default aria- role for the header element is header role=banner,
so you
do not need to set it.
Thank You,
Barry Smith
Re: [whatwg] IPv4 parsing
On 24 Jun 2015 at 20:15, Peter Kasting pkast...@google.com wrote: How Chrome's omnibox handles this (which I think is compliant with most other places): If there are no dots in the middle of the expression, the number is converted to powers-of-256 format and leading 0s are prepended to reach four octets: 66 = 0.0.0.66 256 = 0.0.1.0 If there are dots in the middle, the number after the last dot is treated as above, while the numbers before the dots must satisfy 0 = n = 255 and are placed into the highest octets in order: 1.66 = 1.0.0.66 1.256 = 1.0.1.0 1.2.66 = 1.2.0.66 1.256.66 = invalid This makes no sense at all. -- Cheers -- Tim
Re: [whatwg] A mask= advisory flag for link rel=icon
To close the loop on this, we will change to link rel=mask-icon href=whatever.svg color=#aabbcc. We like the idea of determining the color from the SVG, but we won't be able to implement in time for this cycle, and having an explicit color override seems useful. So for now we'll implement explicit color and we'll consider automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Regards, Maciej On Jun 17, 2015, at 3:32 PM, Maciej Stachowiak m...@apple.com wrote: Out of curiosity, I understand that flat design is fashionable right now and you might want single colour icons to represent web sites in Safari, but what is your fallback for the billion or so web sites which currently only provide a multi-coloured icon? I assume you just display the icon they provide? Details of the UI of the pinned tabs feature are a bit out of scope for this mailing list, but since it might provide useful context to people, here are some facts: - We sometimes display the mask icon in the specified color, and sometimes in a medium grey. - We I meant to say - If no mask icon is provided, we will fall back to a monochrome monogram for the site rather than the full-color icon, in the context where mask icons are currently used. Regards, Maciej
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote: Also fun and probably worth documenting is how http://127.1/ and http://127.2.1/ are parsed. I doubt the average developer knows (unless they specifically deal with low level networking). The question is whether the parsing happens at the URL parser layer or at the network layer. You have http://0.0.0.66/ that's not a match for your example... I'm not sure what you mean here. -- https://annevankesteren.nl/
Re: [whatwg] Site-Wide Heading Element
On 6/24/15, Barry Smith bearzt...@live.com wrote: On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote: Hi Barry — When I build a website that is to have more than one page, and I want the banner to be the same across all pages, I use the header element with a javascript file embedded inside, like this: header id=banner script src=scripts/header.js type=text/javascript/script /header Your first priority should be to fix that to ensure that your pages are usable when scripts are turned off or not supported. See WCAG. -- Garrett @xkit ChordCycles.wordpress.com garretts.github.io personx.tumblr.com
Re: [whatwg] A mask= advisory flag for link rel=icon
On 06/24/2015 08:33 PM, Kevin Marks wrote: Does this mean we can now have rel=icon with SVG instead of providing a bitmap for every iOS device specifically (when we add to homepage)? Do chrome and Firefox support SVG icon images? Here's a simple testcase: http://people.mozilla.org/~dholbert/tests/favicon/test1.html Firefox 41 (currently on Nightly, hitting release in late September) supports SVG favicons. (Earlier versions have partial support due to a bug with our favicon cache - the SVG favicon would work on first load, but would fail to show up on subsequent loads. That was fixed here: https://bugzilla.mozilla.org/show_bug.cgi?id=366324 ) From my brief testing with my testcase above (Chrome 45 dev channel on linux, Edge on Win10, Safari 8 on Yosemite), it doesn't look like other browser support SVG favicons right now, though. ~Daniel
Re: [whatwg] A mask= advisory flag for link rel=icon
Does this mean we can now have rel=icon with SVG instead of providing a bitmap for every iOS device specifically (when we add to homepage)? Do chrome and Firefox support SVG icon images? On 24 Jun 2015 2:40 pm, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak m...@apple.com wrote: To close the loop on this, we will change to link rel=mask-icon href=whatever.svg color=#aabbcc. We like the idea of determining the color from the SVG, but we won't be able to implement in time for this cycle, and having an explicit color override seems useful. So for now we'll implement explicit color and we'll consider automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Sounds acceptable to me. What's the grammar of color=''? Just hex, or full CSS color? (Either is fine with me.) ~TJ
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 7:21 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote: You have http://0.0.0.66/ that's not a match for your example... I'm not sure what you mean here. You swap between 0.0.0.66 and 66.0.0.0 in your OP. ~TJ
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You swap between 0.0.0.66 and 66.0.0.0 in your OP. Actually, the input URL in that case is different. 0x42.0. != 0x42. Well *that's* confusing. ^_^ Def spec this in detail, please. ~TJ
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You swap between 0.0.0.66 and 66.0.0.0 in your OP. Actually, the input URL in that case is different. 0x42.0. != 0x42. -- https://annevankesteren.nl/
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 9:37 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You swap between 0.0.0.66 and 66.0.0.0 in your OP. Actually, the input URL in that case is different. 0x42.0. != 0x42. Well *that's* confusing. ^_^ Def spec this in detail, please. How Chrome's omnibox handles this (which I think is compliant with most other places): If there are no dots in the middle of the expression, the number is converted to powers-of-256 format and leading 0s are prepended to reach four octets: 66 = 0.0.0.66 256 = 0.0.1.0 If there are dots in the middle, the number after the last dot is treated as above, while the numbers before the dots must satisfy 0 = n = 255 and are placed into the highest octets in order: 1.66 = 1.0.0.66 1.256 = 1.0.1.0 1.2.66 = 1.2.0.66 1.256.66 = invalid PK
