Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 4/1/2015 9:59 PM, Bobby Mozumder wrote: On Mar 31, 2015, at 12:43 PM, Joshua Cranmer pidgeo...@verizon.net wrote: On 3/30/2015 10:02 PM, Bobby Mozumder wrote: One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Technical discussion is the last step of the process. The reason why people haven't provided technical feedback is because you have failed to motivate your proposal. I gave a limited one-page idea for now, so design faults should be obvious. No. Simple examples don't make design faults obvious, they hide all but the most obvious design faults. My experience with designing APIs is that they can't be fully evaluated until you've tried to use them in their intended scenarios and discover the pain points. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. Most of the unnecessary arguments against it boil down to people just stuck in their comfort-zone, and those people aren’t the target audience for this proposal anyways. Javascript people are going to be happy with their existing selection of MVC frameworks, so why would they want anything new like this? The mistake Javascript developers are making is that they make the assumption that everybody else is a Javascript developer. Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone should get a PhD in Javascript like I did!” which obviously isn’t going to happen. So, if there are technical faults with the proposal here, definitely list them. (or preferably in the Github, where I can keep track of issues directly) Attacking your detractors with ad hominems is a great way to get yourself ignored. People aren't saying those things--they're questioning the utility of your proposal in the first place. You take it for granted that HTML needs a complex, SQL-based MVC framework. You take it for granted that JS is the devil and should be avoided. You appear to take it for granted that using JS frameworks is a problem that needs to be solved. These views are not commonly held on this mailing list, and you're completely ignoring the feedback which is, in effect, questioning these assumptions. Not ad hominem. I’ve literally had developers tell me everyone should learn Javascript. Example: https://twitter.com/yoavweiss/status/582490158496419840 You said, and I left your original quote, wveryone should get a PhD in Javascript whereas your detractor said [everyone] should all learn JS. There is a big difference between the two statements, and belittling that difference makes you seem petty. That's obviously a horrible idea. Why would anyone encourage millions of other people to do more work? Everyone’s time is limited. Why should a fashion-blogger spend time to learn JS to get a responsive high-speed site? They have other things to worry about, like next season’s collections. The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. Years ago, when I first learned HTML in a class, one of the assignments had us make a table of links. I decided to make the links all point to different sites than their text indicated--and realized that the http: link in the status bar would give the game up. After asking around, I was told how to change the status bar text using JS, and then proceeded to copy-paste-tweak that into my desired goal. At that time, I didn't know how to program, and certainly never knew JS. I bring this example up because it shows that people who are motivated to solve a problem will take the time to figure out how to do so--even if it requires technologies they never learned. You’re asking people to learn Javascript, an MVC framework, and its associated templating system, to fix a basic user experience problem with the web. I was talking with a Tumblr power user a couple of days ago about this and she confirmed that all Tumblr kids pretty much know the basics of HTML, somewhat fewer people know CSS, and nobody knows Javascript. Tumblr maintains about 200 million sites. Pay attention to your quote. They know the basics of HTML, not they know most of HTML nor they know the complex bits of HTML. The central fallacy of your argument is that you're arguing that translating a complex design pattern from JS to HTML will automatically make people learn it, and your own quote disproves that fallacy. This points to an obvious meta-design flaw: you're constructing a proposal based on intermediate programming principles (MVC and database query), motivating it based on perceived utility (not usability) to non-programmers, and finally resisting any
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 3/30/2015 10:02 PM, Bobby Mozumder wrote: One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Technical discussion is the last step of the process. The reason why people haven't provided technical feedback is because you have failed to motivate your proposal. Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone should get a PhD in Javascript like I did!” which obviously isn’t going to happen. So, if there are technical faults with the proposal here, definitely list them. (or preferably in the Github, where I can keep track of issues directly) Attacking your detractors with ad hominems is a great way to get yourself ignored. People aren't saying those things--they're questioning the utility of your proposal in the first place. You take it for granted that HTML needs a complex, SQL-based MVC framework. You take it for granted that JS is the devil and should be avoided. You appear to take it for granted that using JS frameworks is a problem that needs to be solved. These views are not commonly held on this mailing list, and you're completely ignoring the feedback which is, in effect, questioning these assumptions. We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Proposal: navigator.cores
On 7/2/2014 8:31 AM, Rik Cabanier wrote: That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor. I went back and looked at the later messages in that thread. Your argument implies that a plurality of engines implementing this feature would mollify the detractors, and that is certainly not my reading. People brought up serious concerns about the utility and wisdom of this API, and summaries like yours very much feel like an attempt to avoid addressing those concerns by creating facts on the ground instead. The concerns I recall off the top of my head, to wit: 1. Fingerprinting 2. Use of the API is implicitly assuming that the browser uses only one thread, which is not a safe assumption. 3. The existence and probable eventual takeover of asynchronous multiple core architectures. 4. There are better ways to achieve the desired use cases. I've personally mused that the usual motivation for this feature is essentially predicated on the notion that there is too much work to be assigned for a weak computer, yet the advocates of this API respond to comments about the problems involved with high dynamic usage of the computer with the scheduler can solve it--the same scheduler whose inability to cope with too much work is the basis for the API in the first place. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[whatwg] More URL spec feedback
Hi, I'm back with more questions on the URL spec after poking at it a bit more for various purposes. One thing I've noticed is that the specification currently aggressively fails IPv6 address matching, so, e.g., new URL(http://[::1::];) would fail. (Although it allows http://[1:2:3:4:5:6::8]/ to go through whereas RFC 5952 advises that :: MUST NOT be used to shorten just one 16-bit 0 field.) However, it doesn't apply this same logic to IPv4: new URL(http://192/;) is parsed as a perfectly valid URL. Is this intentional? -- Joshua Cranmer Source code archæologist -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[whatwg] URL spec and IDN
I've noted that the URL specification is currently rather vague when it comes to IDN, and has some uncertain comments about issues related to IDNA2003, IDNA2008, and UTS #46. Roughly speaking, in my experience, there are three kinds of labels: A-labels, U-labels, and displayable U-labels. A-labels are the Punycode-encoded version of the labels used for DNS (normalized to ASCII lower-case, naturally). U-labels are the results of converting an A-label to Unicode. Displayable U-labels are A-labels converted to U-labels only if they do not contain a Unicode homograph attack. My drawing a distinction between the displayable U-label and the regular kind is out of concern that the definition of displayable may change over time (e.g., certain script combinations are newly permitted/prohibited), whereas the U-label derived from an A-label should be constant. Given these three kinds of labels, it ought to be possible (IMO) to convert a generic domain in any (i.e., unnormalized) format. The specification currently provides for a domainToASCII and a domainToUnicode function which naturally map to producing A-labels and U-labels, but contains a note suggesting that they shouldn't be implemented due to the IDNA clusterfuck. The way to a displayable U-label would seem to me to come most naturally via |new URL(http://; + domain).host|. Looking at the spec, it's not clear if the host, href, and other methods are supposed to return U-labels or A-labels (or some potential mix of the two). Running some tests appears to indicate that Firefox, Chrome, and IE actually all do different things: * Firefox appears to use displayable U-labels (i.e., the result matches what is seen in the address bar) * Chrome appears to always use A-labels * IE appears to always use U-labels (on http://☃.net, the address bar displays http://xn--n3h.net but location.href returns http://☃.net). I'm guessing the reason why the domainTo* methods are unspecified are due to inconsistent handling of IDNA2008 by current web browsers, although it appears to me that a consensus has emerged on implementation. Chrome and IE appear to roughly implement UTR #46 transitional mode: * Uses Unicode $RELATIVELY_NEW for case folding/mapping * Processes eszett, final sigma, ZWJ, and ZWNJ according to IDNA2003 (UTR #46's transitional) instead of IDNA2008 * Symbols and punctuation are allowed, in violation of IDNA2008. * The BiDi check rules appear to follow IDNA2008 instead of IDNA2003. Neither Chrome's documentation nor IE's documentation are explicit about the changes (sufficiently so, at least, for someone like me who doesn't know all that much about how IDNA* is implemented but rather wants to make sure things work correctly and safely). * They do not appear to enforce IDNA2008's contextual rules (again, the documentation is slightly unclear). * Chrome's documentation calls out ignoring STD3 rules (i.e., permitting more ASCII characters) and disallowing unassigned code points. IE's documentation does not suggest what they do here. Firefox still implements IDNA2003, but this is only because the person who would be implementing IDNA2008 lacks the time. Given these facts, I'd like to propose changes to the URL spec to better specify and more reliably reflect IDN processing as is currently done: 1. Expressly identify how to normalize and process an IDN address under IDNA2008 + UTR #46 + other modifications that reflects reality. I'm not qualified to know what happens at precise edge cases here. 2. Resolve that URL should reflect U-labels as much as possible while placing the burden of avoiding Unicode homograph attacks on the browser implementors rather than JS consumers of the API. 3. The comments about avoiding implementation on domainTo* methods should be dropped. 4. Tests should be added to ensure that domain labels are processed correctly. There is already a testsuite for UTR #46 processing available at http://www.unicode.org/Public/idna, which I suspect could be adapted into a testsuite for processing domain labels. 5. Browser vendors should implement domainToASCII and domainToUnicode to at least as well as they internally implement these methods, even in lieu of precise definitions on how to handle IDN. In any case, I'd rather have IDN handling that matches how my browser implements it internally than one that matches an official, blessed spec, if the two diverge. Note that this includes handling deciding when U-labels are safe to display (assuming that browsers are competent to enough to already think about this). -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On 8/7/2013 5:28 AM, Anne van Kesteren wrote: On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. There are enough places in my code where being able to decode/encode base64 from a typed array is a necessary step that I added helper functions to do this locally, particularly when I am about to shove it through charset conversion as well. Eliminating a copy step would be useful, although I don't think I'm pushing enough data through this functions to make a noticeable performance difference. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth E
Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder
On 8/7/2012 12:39 AM, Jonas Sicking wrote: Hi All, I seem to have a recollection that we discussed only allowing encoding to UTF8 and UTF16LE, UTF16BE. This in order to promote these formats as well as stay in sync with other APIs like XMLHttpRequest. However I currently can't find any restrictions on which target encodings are supported in the current drafts. One wrinkle in this is if we want to support arbitrary encodings when encoding, that means that we can't use insert a the replacement character as default error handling since that isn't available in a lot of encoding formats. I found that the wiki version of the proposal cites http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html as the way to find encodings. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder
On 8/7/2012 12:48 PM, Joshua Bell wrote: When Anne's spec appeared I gutted mine and deferred wherever possible to his. One consequence of that was getting the other encodings for free as far as the spec writing goes. If we achieve consensus that we only want to support UTF encodings we can add the restrictions. There are use cases for supporting other encodings (parsing legacy data file formats, for example), but that could be deferred. My main use case, and the only one I'm going to argue for, is being able to handle mail messages with this API, and the primary concern here is decoding. I'll agree with other sentiments in this thread that I don't particularly care about encoding to anything other than UTF-8 (it might be nice, but I can live without it); it's being able to decode $CHARSET that I'm concerned about. As far as edge cases in this scenario are concerned, it pretty much boils down to I want to produce the same JS string that would be output if I looked at the text content of the document data:text/plain;charset=charset,data. When encoding, I think it is absolutely necessary to enforce a uniform guidelines for the output. When decoding, however, I think that most differences (beyond concerns like the BOM) are a result of buggy content creators as opposed to the browser media. Given that HTML display has apparently tolerated differences in charset decoding for legacy charsets, I suppose it is possible to live with a difference of exact character decoding for various charsets--in other words, turning the charset document into an advisory list of both minimum charsets to support and how to do so. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Specs for window.atob() and window.btoa()
On 02/05/2011 08:29 PM, Jonas Sicking wrote: So my first question is, can someone give examples of sources of base64 data which contains whitespace? The best guess I have is base64-encoding MIME parts, which would be hardwrapped every 70-80 characters or so. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] HTML6 Doctype
On 08/29/2010 11:33 AM, David John Burrowes wrote: As I see it, if I'm developing for other major platforms (java, osx, windows, ...) I have a fair degree of certainty which versions of those platforms support what features, and that's really useful in situations where I'm targeting (either for development or support) the non-current version. So, I have some trouble understanding why it is good to put (what I hope will be) a lot of innovation in just the HTML spec into one undifferentiated definition. (and, presumably similar stories for the other standards specs) OS X and Windows both pretty much have one implementation (WINE is not sufficiently complete or important to count in this regard), and Java is largely driven by a single implementation. So you can delineate support primarily by what this version supports.--you don't have to worry about differences between different implementations. HTML and CSS have at least four major independent implementations (Gecko, Webkit, Trident, Presto, and there are other notable but not quite so heavy market share implementations). That means that features are implemented and experimented on at four different rates; the exact level of support for a particular version would be different for all of them, at least until they all fully implemented it (leaving aside the exact definition of full implementation). Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know Can I use this feature in this browser? So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables that you think are indicative of a problem are what web authors would actually use in real life. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Dates BCE
David Singer wrote: Against that, one has to realize that the label of the day before X is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. In neither the Gregorian nor the Julian calendars is there a year 0, as used in conventional speech (formats designed for machine computation treat the issue a little differently). -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] A New Way Forward for HTML5
Manu Sporny wrote: form consensus: fail (but that's what the W3C is for, right?) From what I've read, there's only one issue of major importance where consensus has failed to form, namely the Great Codecs Debate. And as representatives have decried the other's positions as complete non-starters (Mozilla and Opera will not license the H.264 codec, and Apple will not accept the Theora codec) for reasons beyond the scope of the WG, there's really nothing that can be done about it. Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn't agree with you, it doesn't go in. If you can't convince him, how would you convince the browsers whose implementations are ultimately important? Browser vendors have in the past shown a willingness to not implement part of the spec if it is untenable. To understand why this is viewed as an issue, we can look to the Microformats community, which has roughly 1,300 mailing list members. Everyone is able to contribute to the main product of that community: The Microformats wiki. Why isn't it the same in this community -- a community that prides itself on being open to everyone? Microformats (AIUI) is easy to implement on top of browser APIs, whereas much of HTML 5 has to be implemented by the browsers themselves. Since the cost of a feature in HTML 5 is much greater than the cost of a new feature in Microformats, why should we expect the two to accept as easily new features? To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base). I think it is fairer to compare the number of people who actually come into contact with HTML: those who write it (or those who write tools to write it) and those who write tools to display it. It is probably a stretch to say that even 1 million of those people will use HTML to a sufficient degree to be impacted by the specification. Most of those 1 billion people would be at an utter loss to even name the format which is carrying their data. I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Using the same tools as everybody else, I can refine the patch until there is a large enough group of people that agree, and implementation feedback to back up the patch, where I may have another chance of resubmitting the patch for re-review. This mechanism is a fundamental part of the community. There is /the/ implementation to the Linux kernel, but there is no implementation of HTML that can be called /the/ implementation. HTML and Linux are incomparable; you'd be much better off comparing HTML and POSIX: they are both descriptions of requirements for implementations. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Chipset support is a good argument
Kartikaya Gupta wrote: I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is. The key point I think you've missed is that putting Theora (or H.264) as THE format in a specification won't make it so. One or the other codec is completely untenable under present circumstances to at least one major browser vendor. It is better that the specification reflect reality--that there is no such format, and there will not be one in the foreseeable future, than that it reflects a mythical utopia. Perhaps what could break the deadlock would be Apple conceding to implementing Theora, or Mozilla conceding to implementing H.264. In either case, the decision to implement would most likely be a result of market pressure, not some arcane specification. Browser vendors can and will ignore specifications if the burden of implementation does not match the value of having it. A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind. I think you have a misconceived notion of the world here, too. Most of the HTML is not manually written by authors, it is automatically generated from programs, be it a Wiki-style generator, or a discrete utility like Dreamweaver. For the most part, those who write these programs--the people who will truly be writing and using the video tags--will be driven by what works in practice, not a statement in a specification that everyone ignores. 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? In short, no. 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? Well, pursuant to the answer to question 1, the choice is either between lying about the reality in claiming something works when it does not or admitting that there is no right answer. Since one of the intents of HTML 5 is to codify the status quo, I think it would be living up to its goal in following the latter steps. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Mike wrote: The benefits? Oh I don't know.. a markup language that supports the transfer protocol it runs on?! Who says you have to serve HTML over HTTP? I see it served via email (and newsgroups), local filesystems, and FTP on a regular basis. Indeed, making HTML depend on HTTP-specific features sounds like A Bad Idea™ (and if you retort XMLHTTPRequest, let me point out that I personally would have objected to injecting HTTP specifics into that interface, had I been around during the design phases). To follow your arguments to the logical conclusion, HTML would have to have special attributes to deal with circumstances within email messages, specific attributes to handle certain filesystem-specific abilities, or quirks of the FTP protocol. I think you'll find such a position untenable; ask yourself then, why limit it to HTTP? -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
