Re: [whatwg] Media query for bandwidth ??
"Michael A. Peters" <mpet...@domblogger.net> writes: > […] > > The small increase in CSS file size doesn't matter with high bandwidth > clients and is justified for low-bandwidth as it reduces the content > that needs to be fetched. > > It would be up to the client to define the device-bandwidth, web > developers should create the CSS for high bandwidth and only have the > alternate CSS kick in when a media query says it is low. > > Honestly I think low or high are the only definitions needed with low > being the only one that a site should have conditional styles set for. I suspect that developers that cared enough to use such a thing would be able to create CSS that is not bloated enough to need the feature … take advertising for example: Almost all pages become smaller without ads and still there exists no element; incentives for advertisers to markup advertisments on web pages do not exist. Same for tracking scripts etc.. Note that browsers contain tools to limit loading speed to e.g. UMTS/3G. Greetings, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] proposal for new inputmode: digits
Eitan Adler <li...@eitanadler.com> writes: > On 25 July 2016 at 14:59, Nils Dagsson Moskopp < > n...@dieweltistgarnichtso.net> wrote: > >> Eitan Adler <li...@eitanadler.com> writes: >> > See also the remainder of my email. >> >> I do not understand. What do you mean? >> > > Please re-read the original email of the thread. > > I am arguing that *neither* > > nor > > are correct. > > While I could understand a keyboard which only allows "allowed tokens" this > is entirely infeasible given modern regular expressions are Turing > complete. In fact, they are infeasible even as DFAs considering valid > values depend on future input. I massively doubt that a “regular” expression could be turing complete. > There is room for a "digits only" inputmode which is *already* a mode > supported by some mobile browsers. I'd only like to make this explicit and > non-magical. Could you qualify the attribute “magical” ? -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] proposal for new inputmode: digits
Eitan Adler <li...@eitanadler.com> writes: > On 25 July 2016 at 13:32, Nils Dagsson Moskopp < > n...@dieweltistgarnichtso.net> wrote: > >> Eitan Adler <li...@eitanadler.com> writes: >> >> > At the moment if you'd like the user to enter *only* digits (no >> separators, >> > +, -, etc.) you must resort to a hack >> > >> > >> > >> > This results in a correct "digits only" keyboard on some mobile keyboards >> > (and nothing on desktops). >> >> Why do you see a problem with that? >> > > Since this is semantically confusing and quite magical behavior. I don't > expect a different keyboard if i provide pattern="hello+ (world|to you)" I suggest to file a bug against your user agent if it does that. Btw, I would appreciate to have some method to input only allowed tokens, even for such a case. >> >> > There are several use cases for digits only, but the main ones that come >> to >> > mind are TOTP codes, CVV codes for credit cards, etc. >> > >> > >> > >> > might work, but is non-obvious and still results in buttons for "+", "-", >> > and "." in some mobile browsers. >> >> This is wrong; text containing only digits is not a number. >> > > I know its wrong. Hence this post. > >> In addition, it may be useful to allow minlengt and maxlength for numeric >> > inputs. This can result in better error messages where the value to be >> > entered needs to be copied from somewhere, and so the minimum and maximum >> > are really proxies for length. >> >> Please continue to use text input elements and the pattern attribute. >> > > See also the remainder of my email. I do not understand. What do you mean? -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] proposal for new inputmode: digits
Eitan Adler <li...@eitanadler.com> writes: > At the moment if you'd like the user to enter *only* digits (no separators, > +, -, etc.) you must resort to a hack > > > > This results in a correct "digits only" keyboard on some mobile keyboards > (and nothing on desktops). Why do you see a problem with that? > There are several use cases for digits only, but the main ones that come to > mind are TOTP codes, CVV codes for credit cards, etc. > > > > might work, but is non-obvious and still results in buttons for "+", "-", > and "." in some mobile browsers. This is wrong; text containing only digits is not a number. > In addition, it may be useful to allow minlengt and maxlength for numeric > inputs. This can result in better error messages where the value to be > entered needs to be copied from somewhere, and so the minimum and maximum > are really proxies for length. Please continue to use text input elements and the pattern attribute. Greetings, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?
Anne van Kesteren <ann...@annevk.nl> writes: > On Wed, May 25, 2016 at 7:32 AM, Михаил Гаврилов > <mikhail.v.gavri...@gmail.com> wrote: >> I propose to standardize locale settings (datetime, number >> delimeters) can be specified only by user via the operating system >> settings. Sites should not change the locale that the user has chosen >> for himself. > > There is a proposal to do that at > https://github.com/whatwg/html/issues/171 but it has not meaningfully > progressed thus far. > > Note also that some sites go out of their way to localize form > controls to fit the language of the site. To the extent they will use > libraries rather than and friends. Arguably they're wrong, but > there are cases where that does make sense. And let's not forget that > users often forget to set these settings properly, that's probably > part of the reason why sites do that kind of thing. In my experience, the “users might have forgotten to set this, so we default to something that is not what the user asked for and create a better user experience” is something that is often invoked by developers that do this stuff, but I have never seen data for/against the claim. Do you have evidence for/against it improving user experience on web pages? -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?
Geoffrey Garen <gga...@apple.com> writes: > Hi folks. > > Should navigator.language and/or HTTP Accept-Language include my > locale in addition to my language — even if the combination is exotic? > > For example, if I speak English but I like Polish number formatting, > should navigator.language report “en-pl”? > > This question came up in WebKit because ECMA-402’s DefaultLocale() > incorporates both language and locale and, to avoid confusion, we > wanted navigator.language, HTTP Accept-Language, and ECMA-402 > DefaultLocale() to agree with each other. It confuses me why you would want to have those three to agree. • navigator.language is the language of the interface • HTTP Accept-Language is the language of content • ECMA-402 DefaultLocale() is the user's locale To me, these seem like completely different things. For example, I am currently on a computer in Germany where LANG is de_DE.UTF-8, but my browser uses HTTP Accept-Language to display web sites in English. > Alexey has raised the point that “English as spoken in Poland” / > “English with a Polish locale” is not a language, and is a potentially > surprising value. Therefore, it might risk breaking websites. Do you have evidence for web sites being broken by this string? > On the other hand, “en-pl” is a syntactically valid BCP 47 language > tag, and it’s the only way to avoid incompatibility between code that > uses ECMA-402 and code that uses navigator.language and/or HTTP > Accept-Language. What incompatibilities are there? I do not understand this. > In researching this question, I discovered that lots of code uses > navigator.language and/or HTTP Accept-Language to infer the user’s > locale, despite the fact that language and locale are not > equivalent. For example, the #1 search result for “infer user locale” > is <http://www.w3.org/International/questions/qa-accept-lang-locales>, > which states, "since many applications need to know the locale of the > user, common practice has used Accept-Language to determine this > information”. > > Regards, > Geoff -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] JavaScript dialogs blocking user experience
Darin Adler <da...@apple.com> writes: >> On Apr 15, 2016, at 9:35 AM, Nils Dagsson Moskopp >> <n...@dieweltistgarnichtso.net> wrote: >> >> Clearly distinguishing between browser chrome and the current document >> interface-wise can be helpful here. While it is incredibly easy to fool >> people in general, browsers that automagically hide the address bar also >> hide information about the state of the browser program. The browser >> still has a state, but it forces the user to remember or deduce it. > > Which browsers automagically hide the address bar? Old versions of Android scrolled the address bar with the content and I found posts that said that “window.scrollTo(0, 1);” could hide the bar. > >> I think a good thing would be to keep browser applications' interfaces >> stable and not change things for the sake of change with every upgrade. > > I believe we are talking about changes that are needed to improve clarity and > security. > > This is a straw man. I can’t think of any browser that changes things > “for the sake of change with every upgrade”. I cannot think of one as well, but desktop environments often change things around without changing actual functionality much – making it harder for users to use the software. For example, GNOME removed the traditional menubar in favor of a “miscellanous” menu bar, then changed its icon from a gear into a “hamburger” icon (≡). And OS X 10.7 (Lion) introduced a leather texture for iCal that as far as I know makes no functional difference and removed it again in OS X 10.9 (Mavericks). > > — Darin -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] JavaScript dialogs blocking user experience
Darin Adler <da...@apple.com> writes: >> On Apr 14, 2016, at 2:17 PM, Arvind Nigam <arvind.ni...@gmail.com> wrote: >> >> My iPad is on iOS 9.3.1, but I was using the UC browser at the time. > > It’s too bad you were using the UC browser. If you had been using > Safari you would not have been trapped by the scam. If you continue to > prefer the UC browser over Safari then you should consider how to let > the developers know you would like to see this improved. > >> I'm guessing that this is still a problem for a lot of users out there > > No question about it. The kind of mitigation we are discussing is > valuable to reduce the effectiveness of JavaScript dialogs as part of > this, but I’m sure the folks perpetrating fraud will find new > effective ways to do so. For example, nothing in browser technology > can prevent a webpage from displaying a misleading message that tries > to trick you into thinking your device is broken or was taken over. Clearly distinguishing between browser chrome and the current document interface-wise can be helpful here. While it is incredibly easy to fool people in general, browsers that automagically hide the address bar also hide information about the state of the browser program. The browser still has a state, but it forces the user to remember or deduce it. Phishing works by confusing the user about the state a program has. Many accessability or security woes can be reduced to hidden state. Tracking using cookies works so well because browsers usually hide cookie state. I think a good thing would be to keep browser applications' interfaces stable and not change things for the sake of change with every upgrade. > > Apple support has a webpage with some advice on this topic that is > updated from time to tome <https://support.apple.com/en-us/HT203987>. > > — Darin -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)
This seems quite simple to me: Use URLs to convey app state. Zac Spitzer <zac.spit...@gmail.com> writes: > But what do end users or developers expect in terms of browser behavior in > this situation? > > The history api (or saving state to indexedDB) aren't going to solve the > problem of reinitialization everytime the user switches back to a web app. > Users expect them to behave like a native app. > > The early iPads were low powered devices and many app developers used to > ship content as images because they couldn't render complex layouts > quickly, but newer tablets are far more powerful and can handle this. > > Chrome handles this as users and developers expect, web apps get paged out > and require a reload depending on memory etc. Safari does it every single > time > > This is a massive barrier against web apps competing against native apps. > On 10 Jun 2015 6:21 am, "Domenic Denicola" <d...@domenic.me> wrote: > >> I'm pretty sure it's out of scope. That's really asking to specify how >> OS-level task switching works. I imagine that Safari-wrapper or whatever >> has decided that when the OS switches back to it it will do a reload, just >> like when I switch back to my mail app it does a sync, and other stuff like >> that. >> >> > -Original Message- >> > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac >> > Spitzer >> > Sent: Monday, June 8, 2015 21:10 >> > To: wha...@whatwg.org >> > Subject: [whatwg] Persistent state for homescreen web apps (without >> > reloading each time) >> > >> > Is it within the scope of the spec to specify whether home screen web >> apps >> > should retain their loaded state when switching from foreground to >> > background and back to foreground again? >> > >> > Chrome behaves exactly as expected, however, iOS reloads the web app >> > each time >> > >> > http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from- >> > ios-home.html >> > >> > -- >> > Zac Spitzer >> > +61 405 847 168 >> -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] Unicode -> ASCII copy/paste fallback
David Sheets <kosmo...@gmail.com> writes: > On Sun, Feb 15, 2015 at 3:16 AM, Glenn Maynard <gl...@zewt.org> wrote: >> On Sat, Feb 14, 2015 at 12:34 PM, David Sheets <kosmo...@gmail.com> wrote: >>> >>> I am writing a documentation generation tool for a programming >>> language with right arrows represented as -> but would like to render >>> them as →. Programmers are used to writing in ASCII and reading >>> typeset mathematics. If I present documentation to them via a >>> purpose-built document browser, I should give them the option (at the >>> generation/styling stage) of making those documents as pleasing as >>> possible. >> >> >> Programmers a decade or two ago, maybe, but not today. >> >> As a programmer, if I see "→" on a page, select it and copy it, I expect to >> copy "→", just as I selected. This sounds like something browsers should >> actively discourage. > > If you're reading documentation which includes types, it's nice to see > implication arrows but copy valid syntax. If you are reading documentation, it is nice to see valid syntax. What if the user is typing the documentation? I can type “→” easily by using a compose key and would be confused if it does not work in the language. > Programming communities which use types or other formal methods > commonly typeset their own documents with mathematical notation. For > practical reasons, they define their language representations using > ASCII. > > If you have nothing more useful to discuss beyond uninformed, > opinionated naysaying, I'll be leaving this thread lie. I find that last paragraph entirely superfluous. Greetings, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Re: [whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding
Ron Waldon jokeyrh...@gmail.com writes: I posted this at http://discourse.wicg.io/ a long time ago and forgot to email the list about it, so here goes... ## original post There's currently no good way to determine whether or not a browser / environment supports GZIP-deflated content entirely from the front-end. Servers can interrogate the Accept-Encoding header when they receive the request, but client-side JavaScript cannot see this value at all. This is important when using a CDN that doesn't facilitate selection of appropriately deflated content (e.g. AWS CloudFront). I've had projects where the initial HTML content is dynamically generated only so that the server can pass the Accept-Encoding header back to the client. That way, the client can adjust the other URLs it uses to pick pre-GZIPed files, e.g. blah.js.gz instead of blah.js all the time. I do not understand that use case. It reads incredibly convoluted to me. The UA controls the transport anyway – it should not make any practical difference to a script how the data is transmitted. Btw, why can AWS CloudFront not into compressed content? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] APIs to interrogate default outgoing HTTP headers, i.e. Accept-Encoding
Ron Waldon jokeyrh...@gmail.com writes: On Tue, 11 Aug 2015 at 08:31 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I do not understand that use case. It reads incredibly convoluted to me. The UA controls the transport anyway – it should not make any practical difference to a script how the data is transmitted. My use case is centred around trying to optimise network usage when requesting content from AWS CloudFront backed by S3. I 100% agree with you that this should not be a script's problem. However, it is. When the server (CloudFront in this case) has raw and GZIP'ed copies of content, and no automatic server-side selection between the two, the only way to optimise network usage is for the script to make this determination. Unfortunately, there is no way to gain access to the default Accept Encoding header from JavaScript, which is necessary to figure out whether to download raw of GZIP'ed content. So we currently do more hoop-jumping by serving a dynamic initial HTML, where the server constructing it can reflect the UA's Accept Encoding header back to the client in a generated script tag. It's yucky. So the server is buggy (for your purposes) and you want to have another feature to work around it. Introducing that will take considerable time and resources. I suggest to just wait until the server is able to serve compressed content transparently or use a more functional server setup. Beyond our own need for access to the Accept Encoding header, there may be other use cases that are supported by providing access to other headers. Btw, why can AWS CloudFront not into compressed content? http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html CloudFront doesn't compress the files itself Amazon S3 doesn't compress files automatically AWS CloudFront will do the right thing if it is backed by a Custom Origin that honours the Accept Encoding header (not S3). We have repeatedly requested improvements from AWS, and they are likely on the way, but we have many hoops to jump until then. When last I checked, many sites using AWS CloudFront and S3, including the first-party AWS Console itself, do not serve GZIP'ed resources, which is sub-optimal. It may take considerable longer time to spec a feature, ship it and wait for user agents to catch up than to just fix your server setup. If your setup really is so buggy that it cannot serve compressed content (Am I understanding it correctly? It sounds so stupid!) switch to something that can, instead of externalizing the costs to UA implementors and future web developers who will have one more interface to learn. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Could you explain how „format“ would work if the content of the element
can not be formated like that? How could attributes be re-formated?
Cameron Jones cmhjo...@gmail.com writes:
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The number of a calendar year really does not fit into to the number
model. Year numbering conveys something different than floating point
numbers or even integers. Standardization of values on ISO years /
proleptic gregorian calendar could prevent quite a few errors here.
Actually, they seem very clearly to be numbers (an integer offset from
some defined 'zero' value, despite some complexities where the zero
and direction of the offset actually differ between CE and BCE) - they
can be incremented or summed meaningfully, even multiplied (although
not squared, most of the time), and unlike, eg., the mentioned:
I consider year-era-constructs as names for a duration of time. We can
have different names than refer to the same duration of time, like 2014
CE and 2557 BE and ROC 103. The fact that most of these calendar
systems use a neutral element (era) and a successor function does not
detract from that: Many contemporary calendar systems also have the
concept of month numbering (february is the second month) - still, in
the interest of localization, the ISO date string value 2014-02 in
input type=month might be rendered as e.g. Februar 2014 (German).
Btw, a meaningful type system should probably prevent you from summing
year numbers. 2012 CE + 2013 CE + 2014 CE should not result in 6039
CE, but a duration of time from 2012 CE to 2014 CE.
On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
[...] car plate numbers, credit card numbers, product numbers, or
social security numbers [...]
they can be usefully selected with varying precision (adjacent years
are closely related, but the next credit card number up is completely
different).
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Interface-wise, a dialog for input type=year without a value might
focus the current year initially - I would consider that a usability
boon. Year selection dialogs do already exist:
That's certainly already possible, and would be undesirable often
enough that it is better not to force it. It could make sense as a
default if a value is not supplied, though.
I do not think the specification should force any interface. It is
just that if I were asked to implement a year picker, it would both a)
focus on the current year if no value was given and b) display the year
number (name) according to the current locale settings.
This rule may not be so useful in general: Digit grouping using dots,
commas or spaces can be useful when comparing smaller and larger
numbers. Consider the following grouping of input type=number:
[ 210 000 ] [+|-]
[ 19 250 ] [+|-]
[ 1 500 ] [+|-]
To me, this suggests that grouping should eventually be a CSS
property. But, personally, I just don't think the problem justifies a
workaround until we can do that.
I sincerely hope grouping does not become a CSS property, as it is
locale dependent. Authors can (and will) ruin this for users not in
their locale.
For CSS it would actually be ok because you could use the lang selector, ie:
input.year:lang(en) {
format: %t;
}
If it was an HTML attribute it would be impossible to define formats for
multiple different locales (other than using an element for each
permutation):
input class=year type=number format=%t locale=en/
Thanks,
Cameron Jones
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] New feature: better integration with browser find interface
David Young dyo...@pobox.com writes: On Mon, Jun 22, 2015 at 11:57:46PM -0700, Mitar wrote: Hi! Followup to this proposal. So after more than half year browsers still have issues searching in dynamic apps. Google Docs can still only intercept ctrl-f, but for people who uses menu search then does not work. It's funny you should mention this, because just last night I was cursing Wikipedia as I tried to search within a page on my iPhone. Wikipedia's default, outline view for mobile makes in-page search ineffective. One way to fix this is for infinite scrolls and other pages that load content on demand to provide methods for the client to ask the server to search/send the on-demand content. Infinite scroll is the halting problem outsourced to Layer Eight. As the user, you never know how much content will come, until it actually ends. This problem can not be solved – except for not using infinite scroll. On the other hand, sometimes it is useful to not allow search to be intercepted. For example, I tend to use browser search for menu in Google Docs to search over comments sidebar, while I use ctrl-f to search the document content. But this cannot really be expected to be clear to users or intuitive. A better integration of such apps with browsers is necessary. I'm not sure I'm picturing the right scenario. It sounds like you want sometimes to limit your search to the comments sidebar, and sometimes to search the document. The search override in Docs is incomplete (it overrides the keychord, not the search method), and a happy side-effect is that initiating a search by different modes (menu, ctrl-f) searches different page content. Is that right? If the web platform provided search within selection, that would be a consistent and learnable way for users to limit their searches. The “web platform” does not do that, browsers do that. The browser I use (conkeror) can already limit commands to specific elements or DOM nodes. For example, prefixing a “c” (copy) command with “* i” limits it to images, prefixing it with “* *” limits it to DOM nodes. The sidebar could be an aside element or something similar as I understand. I think mixing of text and meta-text often creates problems. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New feature: better integration with browser find interface
Mitar mmi...@gmail.com writes: Followup to this proposal. So after more than half year browsers still have issues searching in dynamic apps. Google Docs can still only intercept ctrl-f, but for people who uses menu search then does not work. On the other hand, sometimes it is useful to not allow search to be intercepted. For example, I tend to use browser search for menu in Google Docs to search over comments sidebar, while I use ctrl-f to search the document content. But this cannot really be expected to be clear to users or intuitive. A better integration of such apps with browsers is necessary. To speak to the contrary: I think that “better integration” is extremely harmful, as long as it violates user expectations. I use the keyboard a lot (my hands hurt when I browse with a mouse) and I absolutely hate it when websites intercept keypresses that the browser UI already uses. Some sites – e.g. GitHub – I can navigate only without JavaScript. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] A mask= advisory flag for link rel=icon
You could just set the colors of all paths to black internally and derive a suitable mask from any SVG logo that way. See any error? Maciej Stachowiak m...@apple.com writes: There’s no technological enforcement that the SVG only uses the color black. We will interpret it as a mask in the same way as the SVG ‘mask’ element, which effectively combines the luminance with the alpha channel. Effectively, this means that other colors will end up partly transparent, so using other colors will probably do something weird, but nothing prevents authors from doing that afaik. The reason for treating the icon as a mask is that we want to enforce having a monochrome shape, specifically for our pinned tabs feature. Regards, Maciej On Jun 15, 2015, at 6:52 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: If I am not mistaken, it should be possible to use the outline shape while not requiring 100% black color for every path in the SVG icon. As I see it, a proper icon has to have a distinctive outline anyway. Karl Dubost k...@la-grange.net writes: Nils, Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net a écrit : Edward O'Connor eocon...@apple.com writes: These images can be tinted to better fit in with the site's theme. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. Ed, maybe, replied already I believed in the sentence above. The mask icon is giving just a shape. So that the chosen theme of the phone can customized the color to its own choice. Be imposed by the brand of the operator, or I guess someone hacking its theme to have its own. see for example http://stackoverflow.com/questions/9711481/icon-color-on-different-themes I guess things like Android theme, icon sets, etc. would give some answers. https://dribbble.com/search?q=+icon+sets+monochrome It's a way for a site to provide a generic shaped icon but that will adjust its colors depending on the theme. -- Karl Dubost http://www.la-grange.net/karl/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Icon mask and theme color
Maciej Stachowiak m...@apple.com writes: […] Where do we go from here: (1) We could add mask or something like it to the standard, and change browsers to ignore mask icons in contexts where they are looking for a regular icon. (2) We could change to a new rel type for mask icons, such as rel=mask-icon, but keep theme-color as the source of the color, with the possibility of darkening light colors used to make light colors viable. (3) We could change to a new rel type for mask icons, such as rel=mask-icon, and give it a color attribute to be used specifically for the icon. We don’t have a strong principle on this, and it’s not too late to change before shipping the release version of Safari 9. We welcome input on which of these would be best, or whether something else entirely is better. (4) Set a MIME type like application/vnd.apple.svg-mask+xml. This might prevent breakage in other browsers and allow opt-in without introducing new attributes. The source of the theme color could then be in the file or in the theme color meta value. (5) Use the shape of the path in the SVG icon as a mask and retain the theme color meta value. Why isn't this done? One could have a properly colored icon for one purpose and use the outline of the same icon for the flat design staff. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] A mask= advisory flag for link rel=icon
Edward O'Connor eocon...@apple.com writes: Lately we've identified a need for an additional advisory attribute for icons. Modern user interfaces have a flatter, more minimal UI style as compared to UIs of the past, and modern devices often feature higher-density displays. Legacy favicons don't really do well in these new environments—they can come off as garish and pixelated. It'd be great if sites could provide a simple, monochrome, scalable icon that would fit right in on modern systems. Such an icon could be used as the default tile image on Windows, as a template image on OS X and iOS, or a system icon in Material Design. These images can be tinted to better fit in with the site's theme. Their shape is important and can be used as a mask which lets the image be used in a variety of UI contexts. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] A mask= advisory flag for link rel=icon
If I am not mistaken, it should be possible to use the outline shape while not requiring 100% black color for every path in the SVG icon. As I see it, a proper icon has to have a distinctive outline anyway. Karl Dubost k...@la-grange.net writes: Nils, Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net a écrit : Edward O'Connor eocon...@apple.com writes: These images can be tinted to better fit in with the site's theme. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. Ed, maybe, replied already I believed in the sentence above. The mask icon is giving just a shape. So that the chosen theme of the phone can customized the color to its own choice. Be imposed by the brand of the operator, or I guess someone hacking its theme to have its own. see for example http://stackoverflow.com/questions/9711481/icon-color-on-different-themes I guess things like Android theme, icon sets, etc. would give some answers. https://dribbble.com/search?q=+icon+sets+monochrome It's a way for a site to provide a generic shaped icon but that will adjust its colors depending on the theme. -- Karl Dubost http://www.la-grange.net/karl/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Using @type on code to specify the computer language
Taylor Hunt taylorcharlesh...@gmail.com writes: Hello, I was wondering about the best way of indicating a code element's contained computer language for syntax highlighting. The specifications are quite clear that using @lang for that is abuse, so many existing implementations use a data-lang attribute, class name, or something similar. I was curious if repurposing the type attribute onto code elements for this purpose would be a good idea. The script and style elements already use it to indicate what language they contain, so there would seem to be precedent. (An argument against this would be input already overloading type's meaning, but that ship may have sailed.) Including non-standard languages within these tags with a differentiating value for type is widely-practiced, such as for HTML templating, or more exotic implementations like in-browser interpreters or thegrid.io's use of style type=text/gss. Using code[type] would have the advantage of an existing vocabulary for unambiguously indicating a code language, through MIME types. It also works today, and should have no problems in older browsers. This proposal would also have the benefit of making it possible to automate generation of the type attribute contents using file(1) or magic(5), which makes it easy to annotate code elements automagically. The most obvious benefit would be syntax highlighting, but there could be other use-cases: more intelligent enunciation by speech synthesizers, for example. It would also make it easier to search for source code examples in a specific language among a large corpus of content. I would love this! -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Supporting feature tests of untestable features
Roger Hågensen rh_wha...@skuldwyrm.no writes: Myself I have to confess that I tend to use caniuse a lot myself. I use it to check how far back a feature goes in regards to browser versions and try to decide where you cut the line In other words I'll end up looking at a featyre and thinking that OK! IE10 supports this feature, IE9 does not, so minimum IE target is then IE10). Then I use that feature and test it in latest (general release) version of Firefox, Chrome, IE, Opera, if it relatively looks the same and there are no glitches and the code works and so on then I'm satisfied, if I happen to have a VM available with a older browsers then I might try that too just to confirm what CanIUse states in it's tables. This still means that I either need to provide a fallback (which means I need to test for feature existance) or I need to fail gracefully (which might require some user feedback/information so they'll know why something does not work). I do not do use browser specific code as I always try to go for feature parity. Have you tried progressive enhancement instead of graceful degradation? I usually build a simple HTML version of a page first, check that it works using curl or elinks, then enhance it via polyfills and other scripts that do their own user-interface enhancements. Of course I consult caniuse in the process to see if features are supported. For me, following a progressive enhancement workflow reduces the need for testing, as the simple (“fallback”) version does usually work if a script does not execute and I can always test it by turning of scripts. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
Majid Valipour maji...@chromium.org writes: For example a news site may want to always send user to the page top where top news are displayed regardless of where the user was before. This is currently being achieved by resorting to workarounds such as setting body size to 100% and using inner divs (e.g., CBC news http://www.cbc.ca/m/news/). Note that many users consider breaking the back button an annoyance. I do not want “take me back where I came from” to suddenly mean “take me back where the site owner would like to me to get”. Especially with “social” news feeds, following a link and then not being able to get back to the position on the page you came from is very frustrating. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
Roger Hågensen rh_wha...@skuldwyrm.no writes: I often open multiple tabs, and then I go through them one by one later. If I end up opening 3-4 videos at the same time I have to stop the other 3 so I do not get a cacophony of 4 videos at once. This is something that can be fixed by the UA: For Mozilla browsers, you can go to about:config and set media.autoplay.enabled to “false”. Also, the NoScript browser extension can make media click-to-play by default. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
Bobby Mozumder mozum...@futureclaw.com writes: Besides, when was the last time you actually wrote a static HTML file? Does anyone do that? I assume you asked a rhetorical question. Still, the answer is “Yes”. For every web site, people actually write templates, not HTML code. This is provably false. Be careful with “all” quantifiers next time. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby Mozumder mozum...@futureclaw.com writes: On Mar 20, 2015, at 12:10 PM, Brian Kardell bkard...@gmail.com wrote: A few things worth noting: First, we've actually tried a bunch of this before, and you're not using it now so I think we can say that at some level it was unsuccessful. Thanks for the feedback here. I just had a quick look at some of the past proposals (XForms, Microdata, XSLT), and they all had clear usability design issues to me. XForms, Microdata and XSLT all do different things. Note that no widely used browser supports XForms in its default configuration; while Chrome, Firefox, Internet Explorer, Safari and Opera all support XSLT. Can you explain the “clear usability design issues” you have seen in XSLT? If so, please do. I suspect that many developers hate to be “forced” by language structure to think about clean abstractions and rather write maintenance-intensive spaghetti code. A friend of mine started learning how to make web pages recently – she was annoyed by the amount of “just use jQuery” (instead of CSS) that came up when she wanted to solve simple layout problems. For this, I focused on presenting the most obvious, usable solution, while trying to be very simple intuitive to a web developer. A usability test would be to see if people understand what I’m proposing. I certainly did not. I would like to see an implementation of your proposal and several demonstrations. Do you have something on hand? […] Already, though, for some reason this proposal went viral. Search Twitter for HTML6 to see what I mean. There are lots of discussions around it out there now, including blog posts and news articles. (It’s already big in Japan.) Here’s an example blog post that discusses this proposal: http://blog.smartbear.com/news/html6-apis-as-natural-friends/ With hundreds or thousands of shares, retweets, upvotes, etc.. it looks like a lot of people want a solution like this. I don’t know how it happened but I believe this represents peoples wide dissatisfaction with having to use Javascript frameworks. I agree in that buzz does not necessarily mean your proposal has merit. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Page refresh interface
Andrea Rendine master.skywalker...@gmail.com writes: Besides that, the spec says that UAs may expose the time (and other aspects) for a refresh event of the document and it also refers to the possibility for a user to cancel the redirect, while as of now users aren't even informed, let alone allowed to interact with this event. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Persistent and temporary storage
Janusz Majnert j.majn...@samsung.com writes: On 13.03.2015 15:01, Anne van Kesteren wrote: On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception if the device runs out of space for whatever reason. There exists also an issue of perverse incentives. If the browser tells an application how much storage it can use, an application developer is likely to try to use the maximum allowed space. This could also lead to web apps refusing to run if an user agent does not report enough space. One solution I know that tries to deal with that is Linux's OOM killer: If you go over the quota, your program is likely to be eaten by a grue. Native apps are not controlled when it comes to storing data and nobody complains. Is there any documentation on how they handle the above scenario? Just write to disk until you hit failure? I think so. This is certainly the case with desktop apps. I also didn't find any mention of quota in Android download manager docs (http://developer.android.com/reference/android/app/DownloadManager.html) or in Tizen's Download API (https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.apireference/group__CAPI__WEB__DOWNLOAD__MODULE.html) Regards, -- Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Unicode - ASCII copy/paste fallback
David Sheets kosmo...@gmail.com writes:
On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
james.m.gre...@gmail.com wrote:
In this case, you can use Unicode escape values by preceding them with a
slash:
.rarr:after { content: \2192; }
This is specified in the CSS 2.1 spec:
http://www.w3.org/TR/CSS2/syndata.html#characters
Personally, I probably would've just started on StackOverflow with this
question (e.g. [1]) but no harm done.
Hi James!
Sorry, I wasn't clear. The issue is not with putting Unicode values
into CSS. The issue is that I would like unicode values to be copied
and pasted as a specific ASCII fallback value.
That is, I would like the equivalent of a rarr; b to appear on a
page but, upon copying, a - b to show up in the clipboard.
I have a solution that works in Firefox 36 (described in original
mail). Chrome 40 does not behave similarly.
I can see some arguments for Chrome's behavior along security lines. I
certainly can understand the utility of Firefox's behavior because I
am writing a documentation generation tool for a programming language
with right arrows represented as - but would like to render them as
→.
I would suggest to use OpenType ligatures for that. You could reasonably
create a ligature font that renders any occurence of “-” as “→”.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Unicode - ASCII copy/paste fallback
David Sheets kosmo...@gmail.com writes: On Fri, Feb 13, 2015 at 12:23 PM, Mathias Bynens mathi...@opera.com wrote: On Fri, Feb 13, 2015 at 1:18 PM, James M. Greene james.m.gre...@gmail.com wrote: In this case, you can use Unicode escape values by preceding them with a slash: OP’s question wasn’t about how to escape non-ASCII characters, but rather about what the copy/paste behavior should be in browsers. @David, I don’t think it’s reasonable to expect non-ASCII characters to be transliterated to ASCII characters copying them. That said, it would be nice to standardize on the behavior here: should generated content be included when copying or not? Hi Mathias, Do you mean that it's not reasonable for transliteration to happen automatically? I agree. What do you mean with “not reasonable” ? I once noticed that where elinks does show “ベルントとウンターアルターバッハの謎”, links shows “BeRuN6TotoU6N6Ta-6A6RuTa-6BaTUHano***”. Now while I cannot read any japanese, I wonder if this transliteration seems unreasonable to you. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Confusion about node1.replace(node2)
Bjoern Hoehrmann derhoe...@gmx.net writes: * Glen Huang wrote: When someone says A replace B, I get the impression that B is no longer in effect and A is the new one. So when I do `node1.replace(node2)`, I can’t help but feel node2 is replaced with node1, which is the opposite of what the spec specifies. To illustrate this, imagine some team sports game where the coach jells Jane, replace John!, in other words, `Jane.replace(John)`. It is clear that Jane is instructed to take the position of John. To elaborate on this a bit: “Jane.replace(John)” takes Jane as the first (implicit) argument and John as the second (explicit), so I read it like “replace Jane and John”. This may look ambiguous – until you remember who is instructed to to the replacement, namely Jane. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: On 2014-11-10 10:35, Anne van Kesteren wrote: On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen resca...@emsai.net wrote: A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. That is what the proposal is doing. The share button would be part of the browser UI. Perhaps you misunderstood it? (However, it is unclear whether all domains are interested in such a migration.) I must have miss-understood, I saw window.close() mentioned and I thought this was a javascript API suggestion for yet another way to sharing things. I looked a bit close now and wonder if this is related in any way to https://wiki.mozilla.org/Mobile/Archive/Sharing ? Do you plan to go for a OpenShare route (modeled after OpenSearch) or something simpler like I mentioned earlier? If all a web author need to do is slap a rel=share on a a tag or a link tag in the head and then have it automatically appear/listed in a browser Share UI for that page then that would be ideal in my oppinion. For the record: Every browser has a “Share UI” already. It is called the address bar. You do not need to do anything to opt into it besides using URLs. Granted, lots of hipster developers bend around backwards to avoid using URLs, but to me it seems you already have a usable mechanism. May I ask if the “share” idea is conflating mechanism and policy? Something like a OpenShare could build further on this hopefully, but for wide adoption the simpler the better. Also OpenSearch is for searching an entire site or parts of it, wile a OpenShare would be just for one page or link so that would be overkill and it would cause another HTTP request to occur which is a waste IMO. I'm also curious if any browsers actually do something if multiple rel=bookmark exist in a page (head and body), are they taken into account in the Bookmark UI at all? I certainly can not recall eve seeing this happen. A quick test in Chrome, Firefox, Opera, IE here with the following in head: link href=http://example.com/test3; rel=bookmark title=Test 3 link href=http://example.com/test4; rel=bookmark title=Test 4 And the following in body; a href=http://example.com/test!; rel=bookmark title=Test 1Click Here1/a a href=http://example.com/test2; rel=bookmark title=Test 2Click Here2/a a href=http://example.com/test0; title=Test 0Click Here0/a The result is the same, if I use the Browser UI bookmark then the head links are ignored, and if I right link the body a link then I'm not given a bookmark choice at all, just copy the url or save it. If bookmark is so ignored perhaps it would be best to take bookmark (and to some extent canonical) and roll that into a rel=share standard which is defined/tied to this activities/intent proposal? Note! Firefox allows right clicking any URL and choosing to Bookmark it, and IE does the same but it called Favorites there instead, in either case I assume that rel=bookmark is ignored and the title is also ignored as the test0 link which does not specify rel bookmark is treated identically to them. Opera and Chrome does not seem to allow right clicking a URL and bookmark it. As I do not have Safari I have no idea what it does in these cases. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for currency input
Michael Gratton m...@vee.net writes: Hi, As the spec currently stands, use of input type=number is unsuitable for currency and other input that require a minimum number of decimal points displayed. When displaying decimal currency values, the typical convention is that a precision of two decimal points is used, regardless of numeric value. That is, one dollar is displayed as 1.00, not 1. However the latter is the result when using input type=number in implementations that follow the spec, such as Chrome and Firefox. Section 4.10.5.1.9 Number state (type=number) currently states: If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number - effectively by calling JavaScript's ToString on the number. This gives rise to the undesirable representation above. Since both the spec and existing implementations use the step attribute to effectively specify the maximum number of decimal points for the representation of the number, it also seems reasonable for the step attribute to also define the minimum. This can perhaps be acheived by changing the definition of the best representation of the number n as a floating-point number to use the JavaScript Number.ToPrecision function, and obtaining the precision from the step attribute, rather than using ToString. This will work for integral currencies by specifying a step of 1, as well as decimal currencies that that use a single decimal point, by specifying a step of 0.1. Thoughts? I think that float is simply the wrong data type for fractional amounts of currency. Let me tell you an abrasive programmer joke regarding that: bool gender; int phone_number; float money_amount; Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] alternate ids for elements
Julian Reschke julian.resc...@gmx.de writes: On 2014-12-03 15:02, Jukka K. Korpela wrote: 2014-12-03, 15:49, Julian Reschke wrote: I have a use case where a certain location in a document can have two anchors (or even more). For instance, in a spec, the author may have specified an anchor, but a section-number based anchor is required as well. Can you elaborate on that? Why cannot you use the same id attribute value in all references to an element? 1.) An author-supplied anchor may change, but you want to preserve existing deep links from other documents. The solution seems simple to me: Do not change the anchor id, ever. Alternatively, wrap the element in a div with a new id. 2.) You may want to support anchors based on section numbers which will allow other parties to link to a specific section of the document while only knowing the section number and a template (think references to sections numbers in RFCs over on tools.ietf.org). I suspect that “section number” and “id” refer to different concepts. How about a new attribute alt-ids which would take a space-separated list of additional anchors? What would be the use of such additional identifiers? See above. Essentially aliases for anchors. The only thing I can imagine right now is a situation where you have an existing id attribute and references to it all around but now need to refer from a context that imposes its own restrictions on the syntax. Say, you have id=παράδειγμα and you need to refer to the element using a URL like http://example.com/foo.html#παράδειγμα; but cannot because the URL needs to be used in an environment where Greek letters cannot be used. But this sounds like a rather rare occasion. It's yet another use case that could be addressed that way. I think this use case could be solved by either URL encoding or transliterating to ASCII. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] alternate ids for elements
Domenic Denicola d...@domenic.me writes: I too have run into this (specifically wanting to preserve old deep-links) and think it would be reasonable, in theory. May I ask why you changed the element ids at all? However, in practice I see no reason for browsers to expend valuable engineering resources on this when an empty `div` (or, more traditionally, an empty `a id=/a`) suffices to give the same functionality. I believe this to be wrong – an empty element does not give the same functionality; a wrapping a or div element, however, does that. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Anne van Kesteren ann...@annevk.nl writes: A couple of us at Mozilla have been trying to figure out how to revive activities/intents for the web. Both work relatively well in closed environments such as Firefox OS and Android, but seem harder to deploy in a generic way on the web. What we've been looking at instead is solving a smaller use case. A Sharing API to start and then hopefully reuse the building blocks for other features that need to be liberated. https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. Our thinking is that something like the overlay browsing context could be reused to make e.g. input type=file or save as extensible going forward. However, admittedly it still doesn't really click. It feels a bit too much like e.g. the various search extensions browsers offer. Too much work for little return. Furthermore, freeing the web somehow from closely knitted silos seems like a worthwhile goal, but is often counter to what those silos are interested in. So it might be that we're still not quite there yet, thoughts appreciated. I would actually love it if I got something more like the search extensions, as they do work unobtrusively and without scripting. I also find creating OpenSearch XML easier than scripting stuff. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: On 2014-11-13 18:19, Nils Dagsson Moskopp wrote: AFAIK, all of these interface details lie outside the scope of the HTML specification (and rightly so, IMHO). If you need a standard symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks like this „“. Then don't spec it but advise or suggest it. Even the bookmark example at https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark says A user agent could determine which permalink applies to which part of the spec thereby acting as a advisory hint/best practice suggestion (note the use of could). I also tested the example code (with doctype html obviously) and the browser behaviouir is still the same, rel=bookmark is simply ignored. In that case shouldn't rel=bookmark be removed from the WHATWG HTML spec to reflect actual use? As long as it is produced and there do exist consumers? Probably not – many browsers also do ignore rel=alternative, the cite attributes on quotations, the datetime attribute on ins and del elements and so on. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I didn't check W3C HTML5 though). The section on the bookmark link type in WHATWG HTML can be found here: https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark The section on the bookmark link type in W3C HTML can be found here: http://www.w3.org/TR/html5/links.html#link-type-bookmark -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: Which brings another issue, how far is too far? Should the naming be standardized as well? Right click a URL on a page and what do you see? Chrome shows Copy link adress Firefox shows Bookmark This Link and Copy Link Location IE shows Add to favorites... Copy shortcut Opera Copy link address Right click a page and what do you see? Chrome shows nothing Firefox shows nothing IE shows Add to favorites... Create shortcut Opera Add to Speed Dial Add to bookmarks Copy address Right click a address field and what do you see? Chrome shows Copy Firefox shows Copy IE shows Copy Opera Copy Very confusing and inconsistent. I'd like to see the following: Right click a URL on a page and see Copy Link Bookmark/Share Link... Right click a page and see Copy Link Bookmark/Share Link... Right click a address field and see Copy Link Bookmark/Share Link... For touch screens/devices holding the finger for x amount of time would equal a right click. Copy Link will simply copy to the clip board. Drag and Drop behaves the same as Copy Link. Bookmark/Share Link... will present a Share API. Opera has a neat thing when you bookmark a page, you are given a option of either a normal bookmark or a Speed Dial bookmark (tiny icon), and it also lets you choose the look of your bookmark (site logo, page thumbnail or text), by the looks of it very easy to add other forms of bookmarks or sharing to that UI (Facebook an Twitter etc.) To me there is no difference between a bookmark of a link or sharing a link, a bookmark is simply you sharing with yourself. I also wonder if a standardized icon/symbol should exist for a Bookmark/Share button on the surrounding UI of a browser. Opera has a heart symbol, Firefox has a star and clipboard/list thingy, IE has a star, and Chrome has a star. A star has been used for Favorite/Bookmark for quite a while. So what about Bookmark/Share ? Does a book with a star make sense or is that too cluttered? Or is Opera on trend with their heart? AFAIK, all of these interface details lie outside the scope of the HTML specification (and rightly so, IMHO). If you need a standard symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks like this „“. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Shared storage
Tobie Langel tobie.lan...@gmail.com writes: On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 15 Feb 2014, Brett Zamir wrote: The desktop PC thankfully evolved into allowing third-party software which could create and edit files shareable by other third-party software which would have the same rights to do the same. The importance of this can hardly be overestimated. Yet today, on the web, there appears to be no standard way to create content in such an agnostic manner whereby users have full, built-in, locally-controlled portability of their data. Why can't you just do the same as used to be done? Download the resource locally (save, using a href download), then upload it to the new site (open, using input type=file)? Because that's a terrible user experience? If that is indeed the case, the terrible user experience is likely a feature of your user agent. Many mobile UAs currently offer several alternatives to the standard file-picker, no change in HTML needed. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Shared storage
Melvin Carvalho melvincarva...@gmail.com writes: On 28 October 2014 21:32, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Melvin Carvalho melvincarva...@gmail.com writes: On 15 February 2014 03:04, Brett Zamir bret...@yahoo.com wrote: *The opportunity and current obstacles* The desktop PC thankfully evolved into allowing third-party software which could create and edit files shareable by other third-party software which would have the same rights to do the same. The importance of this can hardly be overestimated. Yet today, on the web, there appears to be no standard way to create content in such an agnostic manner whereby users have full, built-in, locally-controlled portability of their data. *Workarounds* Sure, there is postMessage or CORS requests which can be used to allow one site to be the arbiter of this data. And one could conceivably create a shared data store built upon even postMessage alone, even one which can work fully offline through cache manifests and localStorage or IndexedDB (I have begun some work on this concept at https://gist.github.com/brettz9/8876920 ), but this can only work if: 1. A site or set of domains is trusted to host the shared content. 2. Instead of being built into the browser, it requires that the shared storage site be visited at least one time. *Proposal* 1. Add support for sharedStorage (similar to globalStorage but requiring approval), SharedIndexedDB, and SharedFileWriter/SharedFileSystem which, when used, would cause the browser to prompt the user to require user approval whenever storing or retrieving from such data stores (with an option to remember the choice for a particular site/domain), informing users of potential risks depending on how the data might be used, and potentially allowing them to view, on the spot, the specific data that was being stored. Optional API methods could deter XSS by doing selective escaping, but the potential for abuse should not be used as an excuse for preventing arbitrary shared storage, since again, it is worked well on the desktop, despite risks there, and as works with postMessage despite it also having risks. 2. Add support for corresponding ReadonlyShared storage mechanisms, namespaced by the origin site of the data. A site, http://example.com might add such shared storage under example.com which http://some-other-site.example could retrieve but not alter or delete (unless perhaps a grave warning were given to users about the fact that this was not the same domain). This would have the benefit above postMessage in that if the origin site goes down, third party sites would still be able to have access to the data. 3. Encourage browsers to allow direct editing of this stored data in a human-readable manner (with files at least being ideally directly viewable from the OS desktop). I proposed something similar earlier, and received a reply about doing this through shared workers, but as I understood it, I did not like that possibility because: a. it would limit the neutrality of the storage, creating one site as an unchallengeable arbiter of the data b. it would increase complexity for developers c. it would presumably depend on the setting of CORS directives to distinguish it from same-domain shared workers. While https://wiki.mozilla.org/WebAPI/DeviceStorageAPI appears to meet a subset of these needs, it does not meet all. +1 Stop doing this. Excuse me? If I am not mistaken, you full-quoted an entire Email just to add „+1“. If you would have done similar in the Google+ Ghetto or on Facebook, I would have no problem with your behaviour. However, on a mailing list, you are annoying people, probably the few hundred or thousand who are subscribed in this case. You are wasting their time – and yours, if I might add … since the WHATWG was not a democracy last time I checked. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Passwords
Roger Hågensen resca...@emsai.net writes: Also http logins with plaintext transmission of passwords/passphrases need to go away, and is a pet peeve of mine, I detest Basic HTTP-Authentication which is plaintext. Note that Basic Auth + HTTPS provides reliable transport security. Hashing the password (or passphrase) in the client is the right way to go, but currently javascript is needed to make that possible. Do you know about HTTP digest authentication? http://en.wikipedia.org/wiki/Digest_access_authentication -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Controlling the User-Agent header from script
Anne van Kesteren ann...@annevk.nl writes:
Per XMLHttpRequest User-Agent has been off limits for script. Should
we keep it that way for fetch()? Would it be harmful to allow it to be
omitted?
https://github.com/slightlyoff/ServiceWorker/issues/399
A possible attack I can think of would be an firewall situation that
uses the User-Agent header as authentication check for certain
resources.
Reporting UA “Mozilla/4.0 (MSIE 6.0';DROP TABLE browsers;--u{!=})”
broke hilariously many sites when I did have set it as my default UA
string, even though I think it conforms to RFC 2616, section 14.43.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Controlling the User-Agent header from script
Roger Hågensen resca...@emsai.net writes:
On 2014-10-13 16:16, Nils Dagsson Moskopp wrote:
Anne van Kesteren ann...@annevk.nl writes:
Per XMLHttpRequest User-Agent has been off limits for script.
Reporting UA “Mozilla/4.0 (MSIE 6.0';DROP TABLE browsers;--u{!=})”
broke hilariously many sites when I did have set it as my default UA
string, even though I think it conforms to RFC 2616, section 14.43.
Again, that's a server security issue and not a browser one, attackers
would never use a nice browser for attacks anyway,
I suspect with some XSS, this might be able to tear a new security hole
with a feature that primarily provides cosmetic benefits.
what point is there in background checks for security guards if the
window is always open so anyone can get in? ;)
Also, a script being able to set a custom XMLHttpRequest User-Agent
would be nice.
Not necessarily replace the whole thing but maybe concatenate to the end
of the browser one?
I'd rather have a prefix, as the RFC says that UA tokens are in
decreasing significance. Does that mean compatibility problems?
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Notifications and service workers
Jonas Sicking jo...@sicking.cc writes: On Tue, Oct 7, 2014 at 5:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote: Though based on Andrew's latest comments, I don't know that anyone strongly feels that we need to keep the event? If you create a non-persistent notification, would you not want to know when the user agent closed it (only relevant if the user agent closes them before the document closes)? If that scenario is not important, we could remove this event too I think. I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I think simple timeouts on anything do not represent good UI. It can be very easy to make non-accessible interfaces using them if a timeout is too short. If you err on the side of caution regarding attention and reading speed that could mean that a timeout becomes largely useless because most users will then dismiss a notification before timeout. Having both an attention deficit and being a fast reader, I am often frustrated with timeout and notification related software issues in multiple ways. For example, I have both experienced not noticing notifications because I was not paying enough attention and being frustrated with notifications opening and closing automatically. Ultimately I see a short timeouts on a notification as an admission that the notification in question is meant to interrupt or at least distract From the current task the user has – if the user does not immediately pay attention, the notification will be gone. this means timeouts do serve as a weak proxy for importance, which people love to lie about. I would probably not use non-persistent notifications myself and hereby urge people to only produce notifications that the user has to clear or none at all. If a notification is not important, just do not use one. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] (no subject)
Silvia Pfeiffer silviapfeiff...@gmail.com writes: On Sun, Sep 14, 2014 at 12:17 PM, javascr...@riseup.net wrote: On 9/12/14, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: What I'd you're a long way away from any medical help? What? s/I'd/if/ (sorry - mobile keyboard) In my mind this is part of the larger drive of the web of things (IoT applied to the web) and needs device APIs. This might not be the right group to discuss it in though. Where is the best place to define the APIs for devices to track, monitor, and surveil us? Perhaps the W3C is the best place. It is funded by the very corporations that are making such monitoring devices and with developer relations experts to tell you how. These corporations are backed by philanthropists, such as William Gates III, whose opposes climate change, whistleblowers, and overpopulation. Sure, Microsoft might've backdoored stuff for the NSA for the past 10 years, and Apple might share your info to the NSA (they'll get it anyway). And Google and the CIA might want info for MindMeld (TM) or Recorded Future, which they openly fund (links below). He who pays the piper calls the tune. You don't have anything to hide, right? Or maybe the question of how or where to best to engineer this or that new gadget is best answered by first asking how to prevent such engineering from being used by a top-down, efficient system. The system is working. That is the problem. http://www.rawstory.com/rs/2014/09/10/cant-wait-for-the-apple-watch-beware-your-fitness-data-may-be-sold-or-used-against-you/ http://rt.com/usa/microsoft-nsa-snowden-leak-971/ Google CIA funded MindMeld https://en.wikipedia.org/wiki/Recorded_Future CIA funded MindMeld http://techcrunch.com/2014/07/17/expect-labs-lands-in-q-tel-investment-will-help-u-s-intelligence-integrate-its-mindmeld-technology/ If you don't want to give your data to anyone, don't. Nobody is forcing you to share your medical data over the Internet. Nobody is forcing you to share your location data over the Internet as well – but somehow, flashlight apps for Android seem to do it at times: http://www.techrepublic.com/blog/it-security/why-does-an-android-flashlight-app-need-gps-permission/ If something is possible, users can be tricked into allowing it – or even pressured. Just look at “enable JavaScript and cookies or a web site that *could* work without both of these will refuse to do that.” I don't see that stopping the world moving forward though. Given that it is happening anyway, I'd rather go with an open API than proprietary ones where we don't know what is happening. I question the assumption that an open standard for something ethically questionable is always desirable. An open standard for voting computers could, for example, lead to more use of voting computers and thus help those who wish commit large scale electoral fraud. I must admit that I am not nearly knowledgeable enough regarding ethical and legal issues surrounding disclosure of medical data. I just think that “shoot first, ask questions later” does not fit in there well. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
Ashley Gullen ash...@scirra.com writes: Am I right that a lot of the mentioned problems stem from old Android devices with browsers that have been shoddily hacked and broken by the manufacturers (presumably in the name of making improvements)? Key words “old devices” and “shoddily hacked”. The first lets me think that new features could never solve old problems – after all, if the UAs would be updated, one could just fix the bugs that existed. The second lets me think that no one – including site authors – would implement device detection and appropriate discrimination correctly. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
Jonas Sicking jo...@sicking.cc writes: In some cases websites uses the UA strings for bad reasons (this is how we've always done it), in other cases because it's literally the best way for them to create a good user experience for their users. I have seen lots of the former and only some of the latter (software downloads for a specific OS / hardware come to mind). Please list examples of “good user experience” for which hardware is needed. […] I'm just suggesting that on platforms where various browsers are *already* exposing a device model through the UA string. That we expose the same information in a more easy-to-consume property in the DOM. My suggested name would be navigator.deviceModel Thoughts? This would lead to yet another entry point for device discrimination. Please do not make this easier. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
Silvia Pfeiffer silviapfeiff...@gmail.com writes: On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? Why don't we provide a better structure and not just a random string. For example: deviceID, browserID, renderingEngineVersion ... Not sure what else would be useful to group actions that the developer needs to take. Haven't looked in detail. This can and will lead to undue discrimination. Not using any of IE, Firefox, Safari or Chrome can already be enough to not be locked out of a site that would work if only a check for a UA string was not there. What developers actually do want to know is if some devices have some capabilities. That something feature detection provides. The UA version or hardware almost always constitutes a hidden query for something else. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Web API for Health Sensors
Erik Reppen erik.rep...@gmail.com writes: It's just a more compact data format that happens to evaluate as an object literal in JS Not always: http://timelessrepo.com/json-isnt-a-javascript-subset -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
Tab Atkins Jr. jackalm...@gmail.com writes:
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
article.recipe:target {
wake-lock: display;
}
That's not a terrible idea.
Thanks. ;)
The CSSWG is generally hesitant to put behavior-altering things in
CSS, but some bleed-through is fine, and this can be argued as an
aspect of appearance.
I think compared to the “will-change“ property, a “wake-lock” property
would fare well. I do wonder, however, how the concept would translate
to different display technologies – like e-ink, which does not need a
wake lock, or physical media, which decompose after some time.
This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).
It would also make it easily possible to express logic similar to “do
not power off the screen immediately after a video is playing” in UA or
even user stylesheets in a no-nonsense and clearly interoperable way.
A CSS solution could also limit abuse if it included a “max-wake-lock”
property.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
Jonas Sicking jo...@sicking.cc writes:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request() calls vs. release() calls
helps, but doesn't fully solve the problem. It's very easy to
accidentally call release too many times, in response to some UI
action for example.
An alternative design would be something like
x = new WakeLock(display);
x.request();
x.release();
Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.
It seems that we already discussed using an object and this solution was
dismissed because of this model being error-prone.
Where was this discussed? Why was it considered more error prone? Was
it related to the patterns discussed at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html
It's also not clear
how this solution is superior than the current solution [1] with regards
to multiple releases or requests. In [1], if you call .request() or
.release() multiple time, the promise reacts appropriately.
The problem arises when you have several semi-independent pieces of
code within a single page. Given that request() and release() is
likely going to happen in response to very different UI events or IO
events, it makes it fairly easy to accidentally have unbalanced calls.
Consider for example a lock which is released either when a video
reaches its end, when the user presses the pause button, or when the
user close the dialog in which the video is rendered. It seems quite
easy to end up with a race where if the user close the dialog right
when the video ends, that release() would get called twice. Or if the
user pause the video first and then close the dialog that release()
would get called twice.
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
article.recipe:target {
wake-lock: display;
}
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] How to determine content-type of file: protocol
duanyao duan...@ustc.edu writes: On 07/28/2014 22:08, Gordon P. Hemsley wrote: On 07/28/2014 08:01 AM, duanyao wrote: On 07/28/2014 06:34, Gordon P. Hemsley wrote: Sorry for the delay in responding. Your message fell through the cracks in my e-mail filters. On 07/17/2014 08:26 AM, duanyao wrote: Hi, My first question is about a rule in MIME Sniffing specification (http://mimesniff.spec.whatwg.org): 5.1 Interpreting the resource metadata ... If the resource is retrieved directly from the file system, set supplied-type to the MIME type provided by the file system. As far as I know, no main-stream file systems record MIME type for files. Does the spec actually want to say provided by the operating system or provided by the file name extension? Yeah, you've hit a known (though apparently unrecorded) bug in the spec, originally pointed out to me by Boris Zbarsky via IRC many months ago. The intent here is basically just whatever the computer says it is—whether that be via the file system, the operating system, or whatever, and whether it uses magic bytes, file extensions, or whatever. In other words, feel free to read that as the correct behavior is undefined/unknown at this point. Thanks for the explanation. Recently, file: protocol becomes more and more important due to the popularity of packaged web applications, including PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app, etc (not all of them use file: protocol directly, but underlying mechanisms are similar). So If we can't specify a interoperable way to determine a local file's mime type, porting of packaged web applications can be problematic in some situations (actually my team already hit this). I know that currently there is no standard way to determine a local file's mime type, this may be one of the reason that mimesniff spec has not defined a behavior here. Well, the most basic reason is because I never delved into how it actually works, because I was primarily concerned with HTTP connections. It's possible that there is no interoperable way to determine a local file's MIME type, but see below. I'd like to propose a simple way to resolve this problem: For mime types that has already been standardized by IANA and used in web standards, determine a local file's supplied-type according to its file extension. This list could include htm, html, xhtml, xml, svg, css, js, ipeg, ipg, png, mp4, webm, woff, etc. Otherwise, UAs can determine supplied-type by any means. I think this rule should resolve most of the interoperability problems, and largely maintain compatibility with current UAs' implementations. There is already a standard in place to detect file types on the operating system level: http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/ http://cgit.freedesktop.org/xdg/shared-mime-info/ I could just refer to that and be done with it. Do you think that would work? (That specification has complex rules for detecting files, including magic bytes and whatnot, and is already used on a number of Linux distros and probably other operating systems.) Maybe no. (1) it's a standard of *nix desktops, I doubt MS widows will adopt it, I see this as pure speculation. and maybe it's a bit heavy for mobile OS; Widely used mobile operating systems are based on Unix (e.g. iOS, Android). Based on your measurements, how long does file(1) take? (2) many packaged web apps are ported from (and share codes with) normal web apps, and most web servers simply deduce mime type from file extension, so doing the same thing in UAs probably results in better compatibility. It may not be possible to deduce the media type from the file extension alone, since there can be parameters to the media type like “charset” or “codecs”, e.g. “text/html; charset=UTF-8” or “audio/ogg; codecs=vorbis”. (3) UAs are already required to do mime type sniffing, which should be enough to correct most wrong supplied-type. Is this interoperable enough yet for the purpose at hand? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
screen timeout to kick in when a display lock is released. I've seen the lack of this many times and it's really annoying. What happens is that after you're done watching a 30 minute movie, the application releases the lock and the screen immediately shuts off. Attempting to work around this by holding the lock for a few minutes past the movie ends means that the application has to guess how long timeout the user has configured his device to. “Do not lock the screen during a movie and some time afterwards” is something that can be done by a user agent quite well. Flash videos never got this right. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Fetch Objects and scripts/stylesheets
Ben Maurer ben.mau...@gmail.com writes: Another concrete example with img tags: sometimes an abusive user will use a site like Facebook as a CDN -- they'll upload a picture and hotlink it from elsewhere. We could insert a time-stamped authentication token as a custom header. Today we sometimes do this via the query string -- giving the user a token that lasts for a few days. This means we bust the user's cache every time we rotate the token. With a custom header, the browser cache stays in tact. Why not just check the referer or origin header and act on that? Images would also be a great example of where logging headers could be extremely helpful. For example, we could log what module within a page rendered an image and monitor bandwidth usage and CDN cache hit rate on a per module basis. In the past it's taken us a long time to debug issues that could easily be found with this method. This means more analytics and logging – privacy intrusions justified by the sheer complexity of systems created by several thousand monkeys on thousands of electronic typewriters. Incidentally, more fingerprinting. I do not see any immediate benefit to the user here. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Canvas-Only Document Type
Brian M. Blakely anewpage.me...@gmail.com writes: The use cases involved are mostly intended for 60fps high-load graphics, so the kind of a11y conditions served by the DOM (screen readers) aren't as helpful in these apps. I don't think the DOM makes videogames more accessible. The Web Platform doesn't serve that case well; it isn't something this is trying to solve. I think no one should ever optimize for inaccessible web content. In case you think otherwise: Would you elaborate why your wish to display “60fps high-load graphics” on the web outweighs the needs of people with old or non widely used hardware or software, people with disabilities, software that has no optical sensory input (e.g. web spiders) and all those of us users who want to zoom or select text? Consider the following: If web content is not accessible by default, only a privileged class of users will be able to see and use it. We had that scenario already when “web” developers used Flash for everything. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: navigator.cores
Eli Grey m...@eligrey.com writes: We want to claim 6 in that situation. If the API claimed less than 6 on Samsung's Exynos 5 Hexa (2x A15 cores + 4x A7 cores), then the cores will be underutilized. Implying it is right for any application to utilize all cores available in a multi-process environment that may or may not exist within a mobile (power-limited) device? Again, this reminds me of the „How can I find out how much RAM I can maximally allocate“ questions. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Inline pronounce element (Tab Atkins Jr.)
Brett Zamir bret...@yahoo.com writes: On 6/5/2014 3:05 AM, whatwg-requ...@lists.whatwg.org wrote: On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris daniel+wha...@honestempire.com wrote: Hello, With existing assistive technology such as screen readers, and more recently the pervasiveness of new technologies such as Siri and Google Now to name two examples, I have been thinking about the appropriateness and potential of having a way to represent the pronunciation of words on a web page. There is currently no other text-level semantic that I know of for pronunciation, but we have elements for abbreviation and definition. As an initial suggestion: pronounce ipa=??a?p?d?iPad/pronounce (Where the `ipa` attribute is the pronunciation using the International Phonetic Alphabet.) What are your thoughts on this, or does something already exist that I am not aware of? This is already theoretically addressed by link rel=pronunciation, linking to a well-defined pronunciation file format. Nobody implements that, but nobody implements anything new either, of course. ~TJ I think it'd be a lot easier for sites, say along the lines of Wikipedia, to support inline markup to allow users to get a word referenced at the beginning of an article, for example, pronounced accurately. Brett Is there any reason one cannot use the ruby element for pronunciation? Example: rubyElfriede Jelinekrp (/rprtɛlˈfʀiːdə ˈjɛlinɛk/rtrp) /rp/ruby -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: toDataURL “image/png” compression control
Glenn Maynard gl...@zewt.org writes: We have an API for compression already. It already supports a compression level argument for JPEG. Having an equivalent argument for PNG is a no-brainer. The only difference to JPEG is that it should be described as the compression level rather than quality level, since with PNG it has no effect on quality, only the file size and time it takes to compress. What benefit does it give then if the result is the same perceptually? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: navigator.cores
Adam Barth w...@adambarth.com writes: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. This script pushed system load to 2.5 for 30 seconds and then estimated I have 4 cores – when running on an old Thinkpad T60 inside Chromium 33. Fact: A sticker on the laptop says “Core Solo”. /proc/cpuinfo agrees. I think it would be a bad idea to expose this information to web applications in an easier and more accurate way for two reasons: First, this enables web application authors to discriminate unduely. Web authors often try to enforce minimal specifications on User Agents if it suits their purpose. Authors often lie to make users more susceptible to tracking and advertising. Enabling authors to discriminate moves the web away from a universal medium – see for example UA string discrimination. I do not want users to see “sorry, this web page needs at least 2 cores” – it will most likely be a lie, similar to messages informing users that they need to allow cookies and JavaScript just to read a web page. Additionally, from a game theory standpoint, I think it is a bad idea to expose the processing resources a client has to applications at all. If a non-malicious application author wants to know the number of cores, then for the purpose of using as much processing power as possible. Applications that grab a maximum number of resources do not play well with other applications that may or may not follow the same strategy. I think a good real-world example how a computing system can handle constrained resources is the OOM killer in Linux. Its simple: If your application uses too much memory, it will be terminated with prejudice. Of course, authors can not know what “too much” means – systems are too diverse for that. This gives an incentive to err on the side of caution, as trying to allocate and use all available memory is most likely fatal. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
David Dailey ddai...@zoominternet.net writes: Addresses frequently, but moreso in cities than in rural areas [2] have the property that 123 Huaihai Zhong Road is geographically between 120 Huaihai Zhong Road and 130 Huaihai Zhong Road, hence obeying the transitive property when articulated into geography. As re-zoning and constructions efforts frequently do not preserve transitive relations, I hereby urge everyone to never rely on it. Also, in Berlin alone, there are at least three house numbering systems, one of them having the numbers wrap around at the end of the street, like: | | 1 2 3 4 5 | I | + +-- = = = = = = + +-- 10 9 8 7 6 | I | | | -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Jonathan Watt jw...@jwatt.org writes: is it wrong to use input type=number for year input. I am certainly not an expert on the topic, but I believe the conceptual problem can be reduced to using an input designed for a group (in the mathematical sensce) to represent a value that is torsor. Quote http://ro-che.info/articles/2013-01-08-torsors.html: While adding two dates is not possible, it is possible to add a time interval to a date («five days from today»). This suggests that we should not confound dates and time intervals — they are different types of values. Therefore asking for a duration using input type=number is fine – asking for a calendar year, however, is obviously a type error. http://math.ucr.edu/home/baez/torsors.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Supporting more address levels in autocomplete
Alex Bishop alexbis...@gmail.com writes: 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. In Germany, forms do have something called „Adresszusatz“ (literally: “address extension”), for everything more specific than name, street, postal code, city. A company campus, for example, may have only one postal address, but mail addressed to a specific division may contain something like “building 3 entrance C”. A person temporarily reachable by mail at someone else's place may have “c/o john doe”. I personally experience problems because of this, as where I live only the apartment number is on the mail box (administration forbids writing one's own name on this) and mail often arrives late because of that. Btw, do we have a collection of real world use cases for address forms? One first thing that came to my mind for me is food delivery services, which have to deal with addresses often and in a timely manner: http://www.lieferheld.de/ has a single input field for each of: - family name - company - street - house number - floor - postal code - city - special directions http://www.lieferando.de has a single input field for each of: - given name - family name - street - house number - company - floor - further information http://pizza.de has a single input field for each of: - company - company division - given name - family name - street - house number - postal code - city - backyard / floor / etc. Based on my small sample, both “company” and “floor” seem to be candidates for address completion. Also, every one of these forms has an address extension field for further information, with different labels. What would be an argument against generic address extension input fields for free form text that does not fit into any other input field? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] hit regions: limited set of elements for fallback content
Steve Faulkner faulkner.st...@gmail.com writes: Nils Dagsson Moskopp wrote: But still, people (with the exception of Paul Graham) stopped using table for layouts if only that were true, take a look at https://www.google.co.uk or grep the html data available from http://webdevdata.org Thanks for pointing out that my assumption was unfounded. I am downloading one of the data sets right now. Also, Faulkner wanting an example of canvas to make accessible ... seems like circular reasoning to me to use that as an example why we need an accessible canvas. ? 1. A wants to demonstrate how technology X can do Y. 2. B: „because A wants to demonstrate how X does Y, we need X to do Y“. reduces to: 3. “X should do Y because someone wants to show how X can do Y.” Am I misunderstanding the argument by a large margin? ?Btw, I have actually read some of your posts regarding canvas accessability and am aware you list quite a lot of arguments.) -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] hit regions: limited set of elements for fallback content
Charles McCathie Nevile cha...@yandex-team.ru writes: On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Dominic Mazzoni dmazz...@google.com writes: First a high-level thought. I'm happy to keep chasing after legitimate use-cases instead of contrived ones, but just because we can't think of one, doesn't mean it doesn't exist... Maybe the vast majority of web apps that use canvas for a grid, or a slider, or a list box would be better off using standard html5 objects. But what if there's one app that can't, for some reason we haven't anticipated? If we wait until that app appears to allow that control to have a hit region, then it will be months or years before that app can be accessible. Which is why I think the but it shouldn't be done that way argument needs to be viewed through the prism of the question but will it? History strongly suggests that people will use canvas because it suits them, whatever experts like us say they *should* do. People also used table for layout and created unskippable flash intros. Web programming might resemble pop culture – it has trends like visitor counters that came and thankfully went away (but then were hip again to show the number of likes or retweets). But still, people (with the exception of Paul Graham) stopped using table for layouts and also do rely less on flash for video content than they did seven years ago. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. It probably is for bugzilla. It isn't for the case where somebody wants a dropdown menu for selecting things, that matches the particularities of their site design. Nor does select work for the case where the site is being built by someone who wants to ensure that their CSS can't be overridden; I don't know why people think this, but many still do. The user should *always* have control. People who “want to ensure that their CSS can't be overridden” are enemies of usability, accessability, by extension also enemies of security and – ultimately – proponents of Digital Restrictions Management. Btw, I use a fixed font and a high contrast GTK+ theme myself – both apply to form controls to make them more usable. It apparently isn't for search suggestions. Whatever the reason, Yandex search doesn't use it for their suggestions. While they don't use canvas either, it seems that select is not sufficient for Yandex. Nor is it used by Google, Yahoo, Bing or Baidu for the task. And none of them have a complicated layout to work with. But they all use styled text elements. Please elaborate: What do you think you can infer from this? Maybe I have not understood the problem these search engines all seem to have. I'll try, though: what if I had a list of choices displayed as a pie chart? Each slice of the pie is a focusable object that, when you click on it, allows you to take an action on that pie slice. What if I look at that page in a textual user agent? Where the hit regions are based on a list as 'fallback content'? You get a list. With links that match the actions. If the developer got accessibility right. If. Contrast the CSS solution, where just removing the obnoxious styling (or visiting the page in a w3m) shows a perfectly usable form – without any additional work from the developer. But if they would only get it a bit right, it seems stupid to suggest that we should gratuitously deny them the option - letting perfect be the enemy of good here is an extremely effective way to reduce accessibility, which is very rarely done perfectly. There are already quite easy options to build accessible web forms. If an author chooses to not make a web page beautiful and sacrifices accessability, that person is certainly optimizing for style and not particularly caring about accessability. I consider this a social problem that may partially be overcome by designing standards (like document formats or protocols) in a way that there exists a way of least resistance for lazy developers. People do accept that some problems can not be solved given
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: CE or BE or ROC do not specify units (successor elements), but points of reference (neutral elements). In my examples, the unit for a time offset is always the duration of a solar year. Yes, sorry, by 'essentially' I meant that they /act/ like and can be treated as such, as a simplification. Looks like a type error to me – similar to the following cases: - octets can be treated as characters, as a simplification - UTF-16 can be treated as UCS-2, as a simplification - REST can be treated as CRUD, as a simplification - HTML can be parsed with regular expr…ZA̡͊͠͝LGΌ The first operand is the name for a duration of time (conveying a start point and an end point), while the second operand is an offset. Suppose the result was displayed using html, like time2014/time: I agree so far, sure, but note also that the year name is itself comprised of an offset and a description of a zero point; 2014 CE is the year starting at the moment when 2,014 years have elapsed from the start of 1 BC. It is itself a number of years, rendered a certain way by convention. - A user agent could localize the result to 2557 BE or ROC 103 or YOLD 3180 without introducing errors into the calculation - similar to an conversion between binary, decimal and hex. Why should it be unable to localize the input (which is done with time zones all the time, btw) ? Sure, you can change the number that corresponds to a given abstract year by changing the zero, and this would depend on knowing the original zero such that it's clear that, for example, '2014' means 2014 CE rather than BE or even BCE (presumably by specification). I think the HTML specification follows ISO 8601 – so yes, 2014 CE. The question is, is it a big enough deal that it demands a new input type, rather than, say, a number and a dropdown with typical eras, provided by the author? That solution leads to the following prerequisites for localization: 1. authors are aware of localization issues 2. authors care about localization issues 3. authors know about user locale 4. authors implement localization 5. authors are competent working with localized data The input type=year solution instead only requires that the web server is able to process ISO 8601 dates. It would place a small one-time burden on implementors, instead of a continuous burden on authors. Or, for that matter, a CSS property telling the browser to display the number following its conventions for year numbers, which could include choice of zero just as much as grouping, as long as the document's choice can be determined. I do not think that localization should be an author's burden. I also do think that localization should not depend on sender, but on receiver. - A user agent could not localize the offset, unless a separate input type=timedelta (or similar) would be introduced. One can use an input type=number for a time offset quite nicely, also see below. Yes, of course. Although I'm not sure what localising an elapsed time would even mean (beyond the obvious choice of characters), except possibly converting it into some non-year unit. See example: 900 seconds or 15 minutes, what would you rather read? I hereby - only half-jokingly - propose a @unit-type attribute for both input type=number and input type=range, which conveys what the given number represents. Thee @unit-type attribute can have the values K, s, m, kg, cd, A and mol to enable hints for the seven SI base units. A microsyntax using the tokens (, ), +, -, *, / and ^ could be used to specify derived units. User agents would be encouraged to localized the displayed data. Example for input element on a cooking form: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep frequency input type=range unit-type=1/s value=1/label A user agent could display this - localized - as follows: temperature [ 180 °C ][+|-] cooking time[ 15 min ][+|-] beep frequency [ each second ][+|-] The @unit-type attribute could also provide useful when allowed on the data, var, output and meter elements. Mark my words. When I first read this, I considered it unnecessary complexity. On reflection, though, I find that I kind of like it. Perhaps it should be allowed for data as well? Of course, I'm not sure that anyone would really use it in practice. Public transport schedule query forms commonly ask how much time you want to have for changing trains at each stop and/or how far the stop is allowed to be from the actual target and how fast you can walk. This common use case already covers time (s), distance (m) and speed (m/s). Those forms use select and option nowadays, see example: https://www.s-bahn-berlin.de/fahrplanauskunft
Re: [whatwg] hit regions: limited set of elements for fallback content
Dominic Mazzoni dmazz...@google.com writes: First a high-level thought. I'm happy to keep chasing after legitimate use-cases instead of contrived ones, but just because we can't think of one, doesn't mean it doesn't exist. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. Maybe the vast majority of web apps that use canvas for a grid, or a slider, or a list box would be better off using standard html5 objects. But what if there's one app that can't, for some reason we haven't anticipated? If we wait until that app appears to allow that control to have a hit region, then it will be months or years before that app can be accessible. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. Absence of evidence is at least weak evidence of absence. Quote http://rationalwiki.org/wiki/Absence_of_evidence: You hear some rustling noises in your backyard, and you want to figure out if the noises were caused by your neighbor's dog or by some other intruder. Fortunately, you know what your neighbor's dog is like - he's rambunctious and he barks constantly. So you listen closely, and after 20 minutes you don't hear any barking. What should you conclude? I'll try, though: what if I had a list of choices displayed as a pie chart? Each slice of the pie is a focusable object that, when you click on it, allows you to take an action on that pie slice. What if I look at that page in a textual user agent? Surely you'd agree that rendering a pie chart is a natural use-case for the canvas element. Nope. If it is just decoration, you should use CSS. Look at source code: http://daten.dieweltistgarnichtso.net/src/css-pie-chart-form.html (For pages like these, I have a hotkey for “disable CSS”.) I know it's technically possible in css, but it's quite tricky - whereas it's simple and natural in canvas. And there are plenty of shapes that are basically impossible in pure CSS. I might consider that a good thing. May I ask if you have designed human-computer interfaces. If so, may you provide examples? What if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. This requests reminds me of customers wanting “page intro in flash.”. If a region has a car theft problem, you don't solve it by giving all the thieves the car keys. You solve it by improving the economy so that thieves have better things to do (like get an interesting job), and you solve the remainder by improving law enforcement. The same applies here. We solve it by providing better tools for custom text editing controls (e.g. better contenteditable APIs), and by making it non-conforming to abuse canvas for this purpose. I'd suggest a different analogy: suppose your company makes foam pipe insulation and you discover people are buying your product and using it as a swimming pool flotation device. Do you try to stop them from using your product and try to get them to purchase other pool toys, or do you start selling your pipe insulation directly to the sporting goods stores? You might check if the pipe insulation is toxic, first. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: The number of a calendar year really does not fit into to the number model. Year numbering conveys something different than floating point numbers or even integers. Standardization of values on ISO years / proleptic gregorian calendar could prevent quite a few errors here. Actually, they seem very clearly to be numbers (an integer offset from some defined 'zero' value, despite some complexities where the zero and direction of the offset actually differ between CE and BCE) - they can be incremented or summed meaningfully, even multiplied (although not squared, most of the time), and unlike, eg., the mentioned: I consider year-era-constructs as names for a duration of time. We can have different names than refer to the same duration of time, like “2014 CE” and “2557 BE” and “ROC 103”. The fact that most of these calendar systems use a neutral element (era) and a successor function does not detract from that: Many contemporary calendar systems also have the concept of month numbering (“february is the second month”) – still, in the interest of localization, the ISO date string value “2014-02” in input type=month might be rendered as e.g. “Februar 2014” (German). Btw, a meaningful type system should probably prevent you from summing year numbers. “2012 CE + 2013 CE + 2014 CE” should not result in “6039 CE”, but a duration of time from 2012 CE to 2014 CE. On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: [...] car plate numbers, credit card numbers, product numbers, or social security numbers [...] they can be usefully selected with varying precision (adjacent years are closely related, but the next credit card number up is completely different). On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Interface-wise, a dialog for input type=year without a value might focus the current year initially - I would consider that a usability boon. Year selection dialogs do already exist: That's certainly already possible, and would be undesirable often enough that it is better not to force it. It could make sense as a default if a value is not supplied, though. I do not think the specification should “force” any interface. It is just that if I were asked to implement a year picker, it would both a) focus on the current year if no value was given and b) display the year number (name) according to the current locale settings. This rule may not be so useful in general: Digit grouping using dots, commas or spaces can be useful when comparing smaller and larger numbers. Consider the following grouping of input type=number: [ 210 000 ] [+|-] [ 19 250 ] [+|-] [ 1 500 ] [+|-] To me, this suggests that grouping should eventually be a CSS property. But, personally, I just don't think the problem justifies a workaround until we can do that. I sincerely hope grouping does not become a CSS property, as it is locale dependent. Authors can (and will) ruin this for users not in their locale. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes: On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I consider year-era-constructs as names for a duration of time. We can have different names than refer to the same duration of time, like 2014 CE and 2557 BE and ROC 103. The fact that most of these calendar systems use a neutral element (era) and a successor function does not detract from that: Many contemporary calendar systems also have the concept of month numbering (february is the second month) - still, in the interest of localization, the ISO date string value 2014-02 in input type=month might be rendered as e.g. Februar 2014 (German). This is all true, but the names we use are typically comprised, essentially, of a number and a unit. Why shouldn't the numerical part still be treated as a number? One would certainly use type=number for a mass or distance, I'd imagine, even though we can have different names that refer to the same mass. CE or BE or ROC do not specify units (successor elements), but points of reference (neutral elements). In my examples, the unit for a time offset is always the duration of a solar year. Btw, a meaningful type system should probably prevent you from summing year numbers. 2012 CE + 2013 CE + 2014 CE should not result in 6039 CE, but a duration of time from 2012 CE to 2014 CE. That seems like a good way of interpreting that, but 2012 CE + 2 (years) must result in 2014 CE. The first operand is the name for a duration of time (conveying a start point and an end point), while the second operand is an offset. Suppose the result was displayed using html, like time2014/time: - A user agent could localize the result to 2557 BE or ROC 103 or YOLD 3180 without introducing errors into the calculation – similar to an conversion between binary, decimal and hex. Why should it be unable to localize the input (which is done with time zones all the time, btw) ? - A user agent could not localize the offset, unless a separate input type=timedelta (or similar) would be introduced. One can use an input type=number for a time offset quite nicely, also see below. I sincerely hope grouping does not become a CSS property, as it is locale dependent. Authors can (and will) ruin this for users not in their locale. I certainly wouldn't wish to give authors any fine-grained control over the grouping, or, for that matter, anything. Instead, I'd have a set of fixed categories of numbers that are typically grouped in unusual ways (vs. the general numerical case), allowing authors to specify what kind of number this is and browsers, then, to use that information to display the number optimally. Of course, it may be that the number of types of numbers is infinite, but I would at least hope that this isn't the case. I hereby – only half-jokingly – propose a @unit-type attribute for both input type=number and input type=range, which conveys what the given number represents. Thee @unit-type attribute can have the values “K, s, m, kg, cd, A and mol to enable hints for the seven SI base units. A microsyntax using the tokens “(”, “)”, +, -, *, / and ^ could be used to specify derived units. User agents would be encouraged to localized the displayed data. Example for input element on a cooking form: labeltemperature input type=number unit-type=K value=453.15/label labelcooking time input type=number unit-type=s value=900/label labelbeep frequency input type=range unit-type=1/s value=1/label A user agent could display this – localized – as follows: temperature [ 180 °C ][+|-] cooking time[ 15 min ][+|-] beep frequency [ each second ][+|-] The @unit-type attribute could also provide useful when allowed on the data, var, output and meter elements. Mark my words. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
Ian Hickson i...@hixie.ch writes: On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. The number of a calendar year really does not fit into to the number model. Year numbering conveys something different than floating point numbers or even integers. Standardization of values on ISO years / proleptic gregorian calendar could prevent quite a few errors here. Some calendars do have an integer offset to the gregorian calendar, allowing localization. If I understand the Wikipedia pages correctly, to get the year in the Thai solar calendar one has to add 543 to the ISO year and for both the Republic of China calendar and North Korean calendar one has to substract 1911. http://en.wikipedia.org/wiki/Thai_solar_calendar http://en.wikipedia.org/wiki/North_Korean_calendar http://en.wikipedia.org/wiki/Minguo_calendar Interface-wise, a dialog for input type=year without a value might focus the current year initially – I would consider that a usability boon. Year selection dialogs do already exist: http://www.yuiblog.com/blog/2009/04/03/multi-layer-calendar/ http://msdn.microsoft.com/en-us/library/windows/desktop/bb760913(v=vs.85).aspx#SELECT_DIFF_YEAR I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. This rule may not be so useful in general: Digit grouping using dots, commas or spaces can be useful when comparing smaller and larger numbers. Consider the following grouping of input type=number: [ 210 000 ] [+|-] [ 19 250 ] [+|-] [ 1 500 ] [+|-] Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Cross-Origin Cookies Sharing Proposal
Huan Du dh20...@gmail.com schrieb am Fri, 21 Jun 2013 19:49:39 +0800: As privacy awareness becomes prevelant, the trend is that future browsers are going to ban third-party Cookies by default. This is a good thing for users, but for giant internet companies, this has no doubt increases the difficult and complexity of implementing user session synchronization. I have a suspicion that the only thing that cannot be done easily without cookies is tracking – that is, pretending that a user has an account, but ensuring that she has not made that choice consciously. Everything else, so it seems to me, can be done RESTful. Am I wrong? Is it possible to, like Cross-Origin Resource Sharing, allow a site to indicate which domains it would like to share Cookies with? The user account management system of Alibaba have encountered this issues and been troubled by this issue. It there's a proposal like this, it would be very nice. Can you elaborate? Why would an account management system need sessions? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Request: Implementing a Geo Location URI Scheme
Rodrigo Polo rodrigo.p...@gmail.com schrieb am Tue, 4 Jun 2013 04:25:49 -0600: Many apps and web browsers make very difficult to work around geo location data, making a URI scheme available in all web browsers could be great, just like mailto:; opens an email client geo: could open your default maps app on desktop or mobile devices, here I give you a more detailed review, an open letter to all web browser devs: http://rod.gs/fixgeo In your blog post, you write: participating on the slow bureaucracy of open web standards isn’t the best idea Elaborate on “best”. What track records do open letters have? Also read: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Do you know about RFC 5870? http://tools.ietf.org/html/rfc5870 There seems to exists a Firefox extension already implementing what you want: https://addons.mozilla.org/en-us/firefox/addon/geo-schema-handler/ The browser Midori already handles geo URIs, Android has a “geo” intent: http://mail.xfce.org/pipermail/xfce/2011-May/028718.html http://developer.android.com/guide/appendix/g-app-intents.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposing: autoscroll event
Kyle Simpson get...@gmail.com schrieb am Tue, 14 May 2013 16:08:17 -0500: There have been times this automatic behavior has been quite annoying because of accidential ID/hash overlap. Please explain how a document subresource can be “accidentally” referred to by a URL be “accidental”. I do not understand it. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposing: autoscroll event
Tab Atkins Jr. jackalm...@gmail.com schrieb am Tue, 14 May 2013 14:34:09 -0700: On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: […] Please explain how a document subresource can be “accidentally” referred to by a URL be “accidental”. I do not understand it. You're using a hash to store information that is used by JS. You also use ids on your page. These can collide unintentionally, causing a scroll on page load. The simplest solution (by far) would be to stop storing “information that is used by JS” in a hash. Even Internet Explorer has pushState() these days: http://caniuse.com/history. Applying private semantics to public resources makes them less accessible for everyone else. IMHO that should not be encouraged. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
alonn alonis...@gmail.com schrieb am Fri, 3 May 2013 18:50:36 +0300: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great Scenario: “You need to enable notifications to view this web site.” With less sarcasm: I think this can and will be horribly abused. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] API to delay the document load event
James Graham jgra...@opera.com schrieb am Mon, 29 Apr 2013 12:50:34 +0200: […] I mean, let's say you delay the load event until after some data has loaded over a web socket. If you try to use that data from the load event handler it can fail in a racy way in UAs that don't support delaying the load event. This also seems like the kind of race that you are more likely to win on a local network, so it wouldn't necessarily be caught during development. With today's web applications one already has to set up a browser instance and run JavaScript until the DOM stops wobbling just to get the HTML the page displays on load. Every single API that makes it easier to build the DOM in JavaScript can and will be used to do so, and in the process, make life harder for everyone else trying to do something (parsing, screenshooting) with such web pages. The turing complete input language that shall not be named is already turning a document load into a halting problem often enough. I would prefer if developers would fix their web pages to not take ages to load. I fear that whatever band-aid the WG will come up with is going to set wrong incentives – making it easier to not send declarative markup and encourage people to violate the principle of least power. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] 2D canvas feature proposal: text decoration
Tab Atkins Jr. jackalm...@gmail.com schrieb am Thu, 18 Apr 2013 13:48:54 -0700: text ... is generally illegal in most civilized places What is this i don't even responding to email on whatwg mailing list leaving out part of the quoted text implying implications I think DD was referring to the following attributes of such “text”: You can't select it, you can't copy it to the clipboard, it's not accessible without a bunch of effort that authors generally don't use. Possibly relevant accessability legislation exists in quite some places: http://en.wikipedia.org/wiki/Accessability#National_legislation That said, I suspect that anything that makes it easier to create text in canvas can and will be used to create inaccessible interfaces. My personal experience regarding web accessability is very frustrating – authors generally do not care, even if they know about it. FYI, I have problems with low-contrast text, but at least I can correct for that using user stylesheets. How would I do that with canvas text? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
Anne van Kesteren ann...@annevk.nl schrieb am Wed, 20 Mar 2013 17:31:14 -0400: If you do an XMLHttpRequest from a document hosted at /superlonghashkeythatactsasauthenticationtoken you probably do not want to expose the Referer header. A GET request should be idempotent, so what would be the problem? If subsequent access changes the state of the resource, that seems broken. Now 1) this document should be hosted over https so this is less likely to be a concern given actual implementations of Referer over https and b) for same-origin requests this matters less (if at all), it still seems better if anonymous is anonymous. I'd suggest using HMACs instead of hashes for signed action URLs. Right? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Priority between a download and content-disposition
Roger Hågensen resca...@emsai.net schrieb am Tue, 19 Mar 2013 14:31:15 +0100: […] What should be shown if there is an issue/conflict? Maybe: Download https://example.com/reports/1/xml/; as report1.xml ? WARNING! File identified as actually being an executable! (*.exe) At least here on Debian GNU/Linux, executables have no file extension. Besides that, what would be the MIME type of windows executables? Or: Download https://example.com/reports/1/xml/; as report1.xml ? NOTE! File identified as not being a xml, appears to be text. (*.txt) So, what about polyglots? http://linux-hacks.blogspot.de/2009/02/theory-behind-hiding-zipped-file-under.html […] The key though is showing: Download url as file.ext ? And in cases where a quick file header scan reveals a possible issue (or simply wrong fileformat extension) either a notice or warning text in addition. But this is only if the user actually hose Save As in the download dialog, they might have chosen Share on facebook or Print or Email to... or even Open a similar but different dialog would obviously be needed in that case. I find all of this approach insanely complex for a negligible benefit. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:41:50 +1030:
[…]
It is rather common to have a channel for a website, not just one
page. There are some exceptions of sites which have subsites with a
channel for each. A {IRC, XMPP} channel is an official chat medium
aiming to serve as an official {support, development, contact}
means. For example, https://developer.mozilla.org/en/Themes
irc://irc.mozilla.org/themedev - discussion of theme development for
Mozilla platform http://www.ubuntu.com/* irc://irc.ubuntu.com/ -
official support channel for the distro the w3c network for
individual sections of website - channels for development
collaboration and meetings c
Those relations are not the same. The Mozilla example shows a
*discussion about* the collection described by by the referring
document, the Ubuntu example shows *support for* the software available
at the referring page. The W3C example is probably similar to the
Mozilla example, only that it would refer to discussions about
documents.
I think a protocol attribute might be redundant as it is a part of
the URL.
Indeed.
It may be worth noting that every part of the note I originally sent
is possible to look up and you can try finding proper way to phrase
things (I have no experience in writing documentation of this sort).
I do not understand.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] use of article to markup comments
Bruce Lawson bru...@opera.com schrieb am Sat, 26 Jan 2013 13:30:18 -: In short, why should the spec suggest any specific method of marking up comments? As someone who is interested in semantics and tired of scraping content and applying scrappy heuristics: If it is clear that an article within an article represents a comments one can easily: * programmatically find article comments in HTML * write interoperable stylesheets for comments, using the selector “article article” * use HTML fragments in a document store for content management (I wrote a blog software with a git backend yesterday and plan to add this feature) Without having one interoperable way all that becomes a lot harder. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] metadata attribute for media
Ralph Giles gi...@mozilla.com schrieb am Tue, 11 Dec 2012 17:23:38 -0800: On 12-12-11 4:58 PM, Ian Hickson wrote: […] I don't think we should have an open-ended API without fixed names, because that is a recipe for an interoperability disaster. I agree it would have interoperability issues. My own implementation experience is that the easy thing to do is to mirror whatever representation your playback framework offers, which can result in per-platform differences as well as per-media-format (and per tagging application, etc.). Just doing “the easiest thing” when you are a content-emitter (e.g. a software developer just mirroring what the platform provides) does make it easier for the sender while making it harder for the receiver – it creates “computational dark energy” that has to be consumed somehow at the receiving side, as someone has to map all of these platform-specific conventions onto common semantics. I rather not have a world in which one needs even more JavaScript blobs just to provide basic functionality cross-browser. That said, I'm not convinced this is an issue given the primary use-case, which is pretty much that web content wants to do more sophisticated things with the metadata than the user-agent's standardized parsing allows. If one cares to that extent, and is already handling format differences, dealing with vendor variation on top isn't that much more effort. I disagree, strongly. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] A plea to Hixie to adopt main
Stewart Brodie stewart.bro...@antplc.com schrieb am Fri, 14 Dec 2012 14:33:43 +: Steve Faulkner faulkner.st...@gmail.com wrote: Stewart wrote: It doesn't necessarily. I've come across pages that expect the head to be displayed too. e.g. tests at http://meyerweb.com/eric/css/tests/css3/like http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side Is this a common mark up pattern? I've not gone looking for any other real-world examples - that's the only one I've seen. However, I can't think of any reason why it shouldn't work, as it's just a block box like the body element (usually) is. I have some rules in my user stylesheet for this – among these one that displays the hyperlink with a small orange feed icon for elements matching „link[rel=alternate][title][type='application/rss+xml']“. I use conkeror (a web browser modeled after Emacs – scripting buffers ful of HTML using JavaScript), the configuration can be found here: https://raw.github.com/erlehmann/dotfiles/27cf8d18faad4d8deeb47ebaadcf91ce26357aa6/.conkerorrc When I tried to actually use this for a web page I found that while Gecko (from conkeror) generates Hyperlinks for link elements, WebKit (at least that from Chromium Version 22.0.1229.94) does not. Therefore, I decided against using this styling pattern for my blog sofware. I suggest people test for themselves, as I suspect I may have done something wrong with my user stylesheets in Chromium – it seems counter-intuitive that a link Element does not create a hyperlink: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTUw%2BPHRpdGxlPkxpbmsgRWxlbWVudCBTdHlsaW5nIFRlc3Q8L3RpdGxlPjxzdHlsZT5oZWFkLGxpbmt7ZGlzcGxheTpibG9ja31saW5rW3RpdGxlXVt0eXBlPSdhcHBsaWNhdGlvbi9yc3MreG1sJ106OmJlZm9yZXtjb250ZW50OidMaW5rOiAnIGF0dHIodGl0bGUpfTwvc3R5bGU%2BPGxpbmsgcmVsPSJhbHRlcm5hdGUiIHRpdGxlPSJGZWVkIiB0eXBlPSJhcHBsaWNhdGlvbi9yc3MreG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvZmVlZCI%2BYm9keQ0K -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:01:26 +1030: On Fri, 1 Feb 2013 05:24:58 +0100 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net Probably associated as in 'have', that a page/site 'has' its channel somewhere. Acknowledge XMPP support in that, might need a 'protocol' attribute or just an xmpp:// URL? “to have” as you use it .ust denotes a relationship exists (as in “I have a sister.”), but not which one. My fault, the question should have been “What noun describes the IRC channel in relation to the web page?”. For a feed, for example, this can be answered with „this is an alternate representation of the content“. A protocol attribute for link elements would be totally hilarious. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Feature Request: Media Elements as Targets for Links
Philip Jägenstedt phil...@opera.com schrieb am Wed, 19 Dec 2012 11:19:14 +0100: On Tue, 18 Dec 2012 22:25:19 +0100, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Nils Dagsson Moskopp n...@dieweltistgarnichtso.net schrieb am Tue, 18 Dec 2012 17:01:40 +0100: […] I therefore prefer a declarative way of linking to timed resources embedded in their original context. Working on a polyfill right now. http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/ I am delighted how useful it is. Is there any implementor interest? Redefining/extending what the fragment component does for HTML is somewhat risky, so it really comes down to what exactly the processing should be. What should a browser do with a URL ending with #foot=10 if there is an element on the page with id=foot=10? What about #foobar if there is an element with id=foo? I would be surprised if treating #foo the same as #foo were Web compatible... I have downloaded an archive of the top 1 HTML files to look into used ID values (thanks to Anne van Kesteren for the hint): http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ The part of the spec that would be affected is http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid, can you give more details about the changes you'd make? When the fragment changes and on page load, the script splits the fragment on „“, interpreting the first part as element ID and the second as media fragment. It scrolls to that element, gives it focus and sets the src of that element to the currentSrc with the media fragment applied. Working code is here; part of it is undoubtedly naive. http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/media-fragments-html-polyfill.js Working from this, my ad-hoc approach would be to insert new steps after step 4 or 6 of the algorithm to determine the indicated part of the document. (I doubt that I am qualified for this, though.) […] - If the decoded fragid includes no U+0026 AMPERSAND character, stop the algorithm here. There is no indicated part of the document. - Let element id be the part of the decoded fragid up to, but not including the first U+0026 AMPERSAND character. If there is an element in the DOM that has an ID exactly equal to element id, then the first such element in tree order is the indicated part of the document, hereafter referred as media element. - If the media element is not an audio or video element, stop the algorithm here. - Let media fragment be the part of the decoded fragid after the first U+0026 AMPERSAND character. - Parse the the currentSrc attribute of the media element, let the address of the current media resource be the result of replacing the fragment component of the URL with the media fragment. - Invoke the media element's load algorithm. […] The drawback of this would be that and element whose ID contains an ampersand would take precedence before media fragments – preserving old semantics, but adding possible headscratchers. Also, img elements could certainly benefit from spatial media fragments. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Feature Request: Media Elements as Targets for Links
Glenn Maynard gl...@zewt.org schrieb am Wed, 19 Dec 2012 08:09:59 -0600: On Wed, Dec 19, 2012 at 4:19 AM, Philip Jägenstedt phil...@opera.comwrote: What should a browser do with a URL ending with #foot=10 if there is an element on the page with id=foot=10? What about #foobar if there is an element with id=foo? I would be surprised if treating #foo the same as #foo were Web compatible... What if the page already uses this format for the hash, and is using the key t for something else? I shouldn't need to worry that my hash keys are suddenly going to gain second meanings. Do you have examples for this? I am not aware of any specification except Media Fragments that uses the key “t”. I reason that if there is no such specification, then that key has no other meaning defined for HTML and URLs. What if the page uses a different format for the hash? I use #foo/bar?a=bc=d (giving me a path segment within the hash, which is extremely useful). The hash is still there. You can still use it for whatever you like, though I suggest you don't – please use history.pushState(). https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history As I see it, the proposed feature could pose a problem for existing web content if all of the following were true: a) author uses a hash of the format “#foo/bar?a=bc=d” b) author has an element on the page with the id “foo/bar?a=b” c) author does not “mean” the fragment to refer to the element d) that element is a media element e) “c=d” (or whatever comes then) is a valid media fragment (With the exception of case c, this can be checked programmatically.) Those who are overloading the meaning of fragments to refer to their private namespaces right now already have to deal with the problem when it occurs (a, b, c). The problem space associated with the proposed feature (a, b, c, d, e) is a strict subset of an already existing problem space (a, b, c) when authors invent private semantics. I think a collision like that is very unlikely. Do you have evidence of content that could break? What if the video element doesn't exist on page load, because it's created by dynamically by a script? We already have the problem of imperative programming where declarative solutions would suffice. AFAIK, if an element does not exist on page load, it is not possible to refer to it in a URL. Can you explain how the proposed feature would make things worse? You can't simply apply the time to every video, since the page might be going through a playlist and you surely don't want t=30 to cause every song or video in the playlist to start at 30s. This is why my feature proposal includes the element id – so one can refer to a specific element. Have you experimented with the polyfill and found breakage in playlists? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
[whatwg] Possible Sub-Delimiters in Fragments (Was: Feature Request: Media Elements as Targets for Links)
Philip Jägenstedt phil...@opera.com schrieb am Wed, 19 Dec 2012 11:19:14 +0100: […] Redefining/extending what the fragment component does for HTML is somewhat risky, so it really comes down to what exactly the processing should be. What should a browser do with a URL ending with #foot=10 if there is an element on the page with id=foot=10? What about #foobar if there is an element with id=foo? I would be surprised if treating #foo the same as #foo were Web compatible... I wrote a script to exctract attribute values and the archive of 8915 HTML pages (http://html5accessibility.com/HTML5data/html.zip). The script and files containing all id and href attributes can be found at http://daten.dieweltistgarnichtso.net/src/htmlattrib. Following are some results for some possible sub-delimiters between element id and media fragment, generated using the following script: = snip = #/bin/sh echo `grep $1 html-attrib-id -c` \ id attributes containing “$1” echo `grep $1\S*= html-attrib-id -c` \ id attributes containing “$1” followed by something containing “=” echo `grep '#' html-attrib-href | cut -d'#' -f2 | grep $1 -c` \ href attributes containing “$1” in fragment echo `grep '#' html-attrib-href | cut -d'#' -f2 | grep $1\S*= -c` \ href attributes containing $1 followed by something containing “=” \ in fragment = snap = From the data set, it seems to me that U+007E TILDE would a pretty safe choice for separation of element id and media fragment if processing should be kept to a minimum (just splitting on the delimiter). With more elaborate processing (only splitting on the delimiter if a U+003D EQUALS SIGN appears after it), we might also use: - U+0021 EXCLAMATION MARK - U+0027 APOSTROPHE - U+002A ASTERISK - U+002C COMMA - U+003B SEMICOLON - U+0040 COMMERCIAL AT I did check for characters U+0028 LEFT PARENTHESIS and U+0029 RIGHT PARENTHESIS but did not include the results for aesthetic reasons. My shell script also does weird things when given an argument of U+002D HYPHEN-MINUS so that is missing as well. Any faults in my reasoning? Also, where do I get a bigger data set? [Boring stuff follows] Regarding U+0021 EXCLAMATION MARK: 4 id attributes containing “!” 0 id attributes containing “!” followed by something containing “=” 2232 href attributes containing “!” in fragment 630 href attributes containing ! followed by something containing “=” in fragment Regarding U+0024 DOLLAR SIGN: 558023 id attributes containing “$” 1 id attributes containing “$” followed by something containing “=” 89837 href attributes containing “$” in fragment 0 href attributes containing $ followed by something containing “=” in fragment Regarding U+0026 AMPERSAND: 78 id attributes containing “” 56 id attributes containing “” followed by something containing “=” 1362 href attributes containing “” in fragment 1346 href attributes containing followed by something containing “=” in fragment Regarding U+0027 APOSTROPHE: 23 id attributes containing “'” 0 id attributes containing “'” followed by something containing “=” 339 href attributes containing “'” in fragment 9 href attributes containing ' followed by something containing “=” in fragment Regarding U+002A ASTERISK: 19 id attributes containing “*” 0 id attributes containing “*” followed by something containing “=” 18 href attributes containing “*” in fragment 0 href attributes containing * followed by something containing “=” in fragment Regarding U+002B PLUS SIGN: 28 id attributes containing “+” 1 id attributes containing “+” followed by something containing “=” 93 href attributes containing “+” in fragment 19 href attributes containing + followed by something containing “=” in fragment Regarding U+002C COMMA: 130 id attributes containing “,” 0 id attributes containing “,” followed by something containing “=” 428 href attributes containing “,” in fragment 10 href attributes containing , followed by something containing “=” in fragment Regarding U+003B SEMICOLON: 88 id attributes containing “;” 0 id attributes containing “;” followed by something containing “=” 222 href attributes containing “;” in fragment 8 href attributes containing ; followed by something containing “=” in fragment Regarding U+0040 COMMERCIAL AT: 8 id attributes containing “@” 0 id attributes containing “@” followed by something containing “=” 208 href attributes containing “@” in fragment 15 href attributes containing @ followed by something containing “=” in fragment Regarding U+007E TILDE: 2 id attributes containing “~” 0 id attributes containing “~” followed by something containing “=” 1 href attributes containing “~” in fragment 0 href attributes containing ~ followed by something containing “=” in fragment -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Feature Request: Media Elements as Targets for Links
Ian Hickson i...@hixie.ch schrieb am Tue, 18 Dec 2012 00:37:12 + (UTC): On Sat, 24 Nov 2012, Nils Dagsson Moskopp wrote: Use Case Description: Linking to specific fragments of media is possible via media fragment URIs [1]. However, it is not possible to apply a link to embedded media declaratively, for example to link to a specific point in time for a media element on a page. [1] http://www.w3.org/TR/media-frags/ Basically, you're saying you have a Web page with a single major video or audio element in it, e.g. the YouTube watch page, and you want to be able to link to that page with a fragment identifier that causes the video to start playing at a particular time, without any scripts involved? My use case: I want to be able to link to a media element in the context of a particular page at a particular time via a URI. Starting playing is something that is already handled by the autoplay attribute, being able to link to an element at a particular time is the issue at hand. Since one can have multiple media elements on a page – for example, in a blog post – I find it important to be able to address a specific element, like http://example.org/podcast.html#episode1t=01:23. (A solution where the fragment addresses the element with parameters would preserve most current semantics. Would using the ampersand for parameters be web-compatible?) Using media fragment URIs for this today I deem not possible in an interoperable way for at least two reasons: First, losing the context of the original page – not only prose, but machine-readable annotations and chapter marks as well. Second, because not all user agents support royalty free media formats, one cannot just link to a single file and expect it to work. Using an audio or video element with multiple source elements I see as the only feasible alternative here. Or is this just an internal-to-the-page thing? As in, you want to be able to, from within a page, cause a media element to seek to a specific time, in response to user interaction, without script? I am currently trying to do both with scripting. It does work, but not very well. Or is relying on scripting ok? Scripting, in this context, does make inferring meaning from URLs hard or even impossible. Not only because everyone is rolling out their own slightly-incompatible and not-interoperable fragment identifier scheme, but in a language-theoretic way. As a developer of both HTML producers and consumers, I try to adhere to the principle of least power. http://www.w3.org/DesignIssues/Principles.html#PLP Today, if the scripting layer fails or changes, the semantics of the URL change. Additionally, implementations may be faulty in subtle ways. For example, if you go to this URL, the script will seek to 0:37, not 02:37. http://warumnicht.dieweltistgarnichtso.net/wn-15.html#t=02:37 I therefore prefer a declarative way of linking to timed resources embedded in their original context. Working on a polyfill right now. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Feature Request: Media Elements as Targets for Links
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net schrieb am Tue, 18 Dec 2012 17:01:40 +0100: […] I therefore prefer a declarative way of linking to timed resources embedded in their original context. Working on a polyfill right now. http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/ I am delighted how useful it is. Is there any implementor interest? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
Stan stas...@orc.ru schrieb am Fri, 14 Dec 2012 11:51:57 +0300: […] The main point, if device ID could be available it would provide more great possibilities for users and web-services. From the top of my head, I can imagine the following possibilities: - persistant device tracking - permanently banning devices for services - mapping devices to users when possible, leaking information Apple iDevices already have unique device IDs, which were described as a tempting opportunity for use as a tracking agent or to correlate with other personally-identifiable information in unintended ways. I suggest you read the following analysis critical of Apple's approach: http://www.pskl.us/wp/wp-content/uploads/2010/09/iPhone-Applications-Privacy-Issues.pdf -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
Stan stas...@orc.ru schrieb am Fri, 14 Dec 2012 11:51:57 +0300: First, I don't think it's convenient for users to register themselves on many sites, which they visit occasionally. If most of the users do this right now, it does not mean they are happy with this, this is bacause there is no other, more simple way (as simple as just clicking on remember me). There is an even simpler way: Not doing registration at all when you do not absolutely, positively need identity. In my experience, that works quite well on blogs and imageboards. [Full disclosure: I have a blog and am a moderator on an imageboard I shall not name.] Second, user accounts are based on e-mails as a rule, which is not unique at all, every user can have multiple e-mails and multiple registrations. Many web-services struggle against users' reputation spoofing made via such fake accounts. I do not understand what is “fake” about such accounts. Third, I think it's up to a certain web-service design and requirements, if it needs to identify user accounts or user devices. For example, usage of the same profile on multiple devices can be a violation of a web-service license agreement, or a web-service may bind several devices to the same profile. I prefer working towards a world where such licensing schemes do not exist. Artificial scarcity introduced by licensing restrictions governing the use of software burdens many so few can profit. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
[whatwg] Fw: Feature Request: Media Elements as Targets for Links
Sorry, forgot to include list. Date: Mon, 26 Nov 2012 21:09:01 +0100 From: Nils Dagsson Moskopp n...@dieweltistgarnichtso.net To: Silvia Pfeiffer silviapfeiff...@gmail.com Subject: Re: [whatwg] Feature Request: Media Elements as Targets for Links Silvia Pfeiffer silviapfeiff...@gmail.com schrieb am Mon, 26 Nov 2012 12:17:34 +1100: […] What is currently possible is a href=#episode1 target=audioWhen Alice mentioned Bob/a and doing the time offsetting in JavaScript, either by changing the currentSrc to something like episode1.oga#t=01:23 or by setting the currentTime to 83. I do something like that already in redokast. […] I would support introduction of a standard attribute for this. Maybe something like @mediafrag=t=01:23 on a elements would be really useful and can be converted by browsers to be added to a video or audio element currentSrc if the a links to the @id of a media element. The biggest problem that I see, however, is that you really want the URL of the Web page be changed to reflect the time offset status of the media resource, e.g. http://example.com/AliceAndBobVideo.html - http://example.com/AliceAndBobVideo.html#t=01:23 . In this way people can cut-and-paste the URL and share it with the time offset intact. I think that solving the problem on the URL level would be much more useful than requiring an additional attribute. Podcasters from Germany calling themselves Podlove initiative are planning to re-use fragment identifiers and a part of media fragments already, but AFAIK there is no implementation of their proposal. http://podlove.org/deep-link/ Your example of http://example.org/podcast.html#episode1t=01:23 seems very usable to me – it would make it possible to have multiple media elements on a page and target them accurately. Maybe one should use another character than the ampersand for compatibility reasons, but that is an empiric question that looking at data can solve. […] I don't think there is a simple way to achieve this with the way that the Web currently works because the interpretation of the fragment parameters of the HTML page are controlled by the Web application where they don't apply to an @id attribute on the page. We would need to change the way in which URL fragments are interpreted by Web pages. Maybe I am misunderstanding you here, but I think the fragment identifier abuse by JavaScript authors can be of use here – it would allow for a simple polyfill that could quickly propagate use and knowledge of such a feature before someone else invents yet another slightly incompatible way of doing the same thing. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Feature Request: Media Elements as Targets for Links
Silvia Pfeiffer silviapfeiff...@gmail.com schrieb am Mon, 26 Nov 2012 00:01:52 +1100: Can you provide an example markup and an example URL that you think will solve your use case? Example markup. Assume I have an audio element in a blog: audio id=episode1 source src=episode1.oga type=audio/ogg; codecs=vorbis source src=episode1.mp3 type=audio/mpeg /audio Someone could comment it like: a href=#t=01:23 target=audioWhen Alice mentioned Bob/a … When someone clicks the link, the browsing context would not change, but the media element would jump to that point (and possibly play). I'm asking because we don't use the name attribute any more in HTML5, because we have the id attribute on all elements. Thus, it is always possible to hyperlink directly to a video element using a hash on a URL and the value of the id element. But I still wonder what you think is missing. I want to hyperlink directly to a embedded media content at a specific time while preserving the context without going through brittle JavaScript hoops. Maybe an element-specific second-hash is possible? Something like http://example.org/podcast.html#episode1#t=01:23 could link to the audio element on the page at a specific point in time. (I am just conjecturing now, though – is that even legal URL synthax?) Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
[whatwg] Feature Request: Media Elements as Targets for Links
Excuse me if I am doing something wrong by submitting this by mail. I am doing this for the first time, trying to fill in the template given at http://wiki.whatwg.org/wiki/Problem_Solving as good as I could. Use Case Description: Linking to specific fragments of media is possible via media fragment URIs [1]. However, it is not possible to apply a link to embedded media declaratively, for example to link to a specific point in time for a media element on a page. [1] http://www.w3.org/TR/media-frags/ - Current Limitations: Linking to media using media fragment URIs changes browsing context. - Current Usage and Workarounds: 1. metavid (Videos of United States Congress) uses JavaScript, even though they have CMML transcripts and SRT. 2. I have a podcast ”Warum nicht?“ generated by a software called redokast. Annotations need JavaScript: Click on the timestamps. http://warumnicht.dieweltistgarnichtso.net/wn-15.html https://github.com/erlehmann/redokast - Benefits: Declarative markup would make referring to timed annotations easier. Referring to a specific point in time in a podcast on the same comments, for example, could be possible. Proposed Solutions: - My Solution: Give HTML media elements a name attribut. Make them valid targets for links with a target attribut. - Processing Model: Processing for media elements and the a element needs to change. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target Change “The target attribute, if present, must be a valid browsing context name or keyword. It gives the name of the browsing context that will be used.” to “The target attribute, if present, must be a valid browsing context name or keyword or the name of a media element in the current browsing context. It gives the name of the browsing context or media element that will be used.” http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0 Append after “If the user indicated a specific browsing context when following the hyperlink, or if the user agent is configured to follow hyperlinks by navigating a particular browsing context, then that must be the browsing context that is navigated.” the paragraph “If the user indicated a media element on the current page when following the hyperlink, then change the currentSrc attribute of the media element to the absolute URL given by the href attribute relative to the URL given by the currentSrc of the media element.”. (I am unsure about relative URIs. Would we need to change only the media fragment, and not re-run the initialization steps? What about the media formats given by source elements?) - Limitations (No idea.) - Implementation: (I am not a very clever guy. Someone would need to fill this in.) - Adoption: Users could easily link to parts of media resources on a page. The solution would be backwards compatible for existing UAs that are able to process media fragment URIs as long as absolute URIs are used. A JavaScript polyfill could be used while not all UAs support this feature. Consumers of web pages could easily see what a discussion about a media resource refers to. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Improving autocomplete
Peter Kasting pkast...@google.com schrieb am Wed, 21 Nov 2012 12:04:56 -0800: […] On the contrary, as a user I find that case extremely compelling. Maybe I'm too easily frustrated, but it's intensely annoying when I have to fill out all my personal information yet again just because I've gone to some new site to buy something. This is far harder on mobile because typing is just a huge pain there and the screen is small enough that I can only see a few fields at once. I have noticed this as well: Several platforms seem to intentionally make it harder to write text – mainly through removal of physical keyboards, taking away pressure feedback and, to a lesser extent modificator keys. The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. Looks like an is-ought-problem to me. The descriptive (“It's already the case …”) can not tell us much about what should be done by virtue of its existence alone. Did you use „new and scary” to imply opponents appeal to tradition? What Chrome can do is started by users; even then a warning is given: http://support.google.com/chrome/bin/answer.py?hl=enanswer=142893 It's important that you use Autofill only on websites you trust, as certain websites might try to capture your information in hidden or hard-to-see fields. Back to your text: I totally agree that we should think hard about privacy and security issues with form autofilling. It's just that I think we're already in a world where we have to think about those concerns (indeed, have been so for awhile), and the specific proposals here don't really amount to a systematic difference in that respect. The systematic difference – for me – is that the proposed functionality may make easier to trick a user into agreeing to „autocomplete everything“ than the current functionality does. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Improving autocomplete
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net schrieb am Thu, 22 Nov 2012 02:11:38 +0100: […] The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. s/users/owners/g ☺ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] checksum attribute in a href tag
A. Rauschenbach rauschenb...@annuo.de schrieb am Fri, 19 Oct 2012 13:50:04 +0200: I'm sick of coping the checksum of important files by hand or QR-code to the download manager or console. To solve the problem I suggest a checksum attribute in the a href tag. It seems that problem is solved at the HTTP level with RFC 1864: http://tools.ietf.org/html/rfc1864 Another advantage is that your visitors (browser) can verify that the document (e.g. a pdf) you linked to is still the same. Cool URIs should not change. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] checksum attribute in a href tag
A. Rauschenbach rauschenb...@annuo.de schrieb am Fri, 19 Oct 2012 20:46:24 +0200: […] If I write an article and link to other documents I want a solution that the visitor can be sure that the document he opens is the document I originally linked to. Mirror the information. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Character-encoding-related threads
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Fri, 19 Oct 2012 20:49:16 +0300: Anyone who bookmarks a document that was not meant to be bookmarked should accept the consequences. What makes the web – and collaboration between entities in general – tremendously useful is that information can be re-used in novel ways the original authors never thought of. A document that is “not meant to be bookmarked” cannot be markedly different from one that is meant to under these circumstances. Yet you seem to deny, a priori, the possibility that a document does not need a title or a name. Care to elaborate? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
