Re: [whatwg] !DOCTYPE htmlbodytablemathmifoo/mi/math/table
On Tue, Dec 13, 2011 at 4:23 AM, Adam Barth w...@adambarth.com wrote: I'm trying to understand how the HTML parsing spec handles the following case: !DOCTYPE htmlbodytablemathmifoo/mi/math/table According to the html5lib test data, we should parse that as follows: | !DOCTYPE html | html | head | body | math math | math mi | foo | table The expectation of the test case makes sense. However, I'm not sure whether that's what the spec actually does. I think that's a spec bug. The net result of which is popping the stack of open elements, but not flushing out the pending table character tokens list. The reason why Gecko does what makes sense is that Gecko uses a text accumulation buffer for non-table cases, too, and any tag token flushes the buffer. (Not quite optimal for ignored tags, sure.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Interaction of wbr and CSS white-space
On Wed, 14 Dec 2011, Boris Zbarsky wrote: On 12/14/11 8:05 PM, Ian Hickson wrote: it was with respect tonobr, which we now define in terms of 'white-space'. Maybe that needs to change? How else would we define it? Whether it's wbr or nobr that gets defined in terms that violate CSS, the result is the same as far as I can tell. If we make a change here it seems better to move towards just specifying everything in terms of CSS, e.g. as the suggestion in my last e-mail on this thread. The question really is whether that CSS-only solution is a plausible way forward or if it has problems I haven't thought of. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reserved browsing context names
On Wed, 14 Dec 2011, Boris Zbarsky wrote: On 12/14/11 7:12 PM, Ian Hickson wrote: One could actually argue that the pages that exist that use _main and _content actually work _better_ in current UAs with those values being interpreted as browsing context names than they would if they were treated as synonyms for _self or _top, because it would let a user open the page up in a window and have the links open in a window next to it, reproducing the old behaviour with secondary browsing contexts. The pages on the _web_ that use them are not using them to do secondary context stuff. The page I linked to that uses _main in fact does worse in UAs that don't do anything special for _main. The page you linked to seemed to me to be a page clearly intended to live in a sidebar so that the user could open a bunch of links up in the main area. Without a sidebar, to replicate the experience you'd need two browser windows side by side with the links opening from one to the other. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interaction of wbr and CSS white-space
On 12/15/11 3:10 PM, Ian Hickson wrote: Whether it'swbr ornobr that gets defined in terms that violate CSS, the result is the same as far as I can tell. Fair. We may need changes or extensions to CSS if nothing else works. If we make a change here it seems better to move towards just specifying everything in terms of CSS, e.g. as the suggestion in my last e-mail on this thread. The question really is whether that CSS-only solution is a plausible way forward or if it has problems I haven't thought of. It seems plausible to me; we should run it by Elika. -Boris
Re: [whatwg] creating a new file via the File API
On Mon, 15 Aug 2011, David Karger wrote: Apologies if I'm revisiting old territory. I've been doing work on pure html/javascript applications that work entirely clientside (http://projects.csail.mit.edu/exhibit/Dido). For persistence, they read and write local files. There's already an input type=file interface for letting the user specify a file to be read. And I can use the same interface, inappropriately, to let the user overwrite a preexisting file. But things get much messier if I want to let the user specify a _new_ file to be written, because the file-open dialog doesn't offer users a way to specify a new filename. What I'd like to be able to do is specify a tag, or a invoke some javascript method, that will produce the save file dialog typical of most systems, with a graphical directory browser but including the option to specify a new filename. This problem isn't unique to me; a discussion on stackoverflow appears at http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file where the proposed solution is to use flash---and that would be an unfortunate loss of html5 purity. They also suggest the hack of using a data: url but that has size limitations. Perhaps input type=file could be given an attribute specifying whether a new filename is permitted? On Wed, 7 Sep 2011, Eric U wrote: This sounds like a job for the FileSaver interface. Currently no browser implements it, but we at Chrome have been considering it. At TPAC last year we discussed it a bit in the WebApps WG meeting; IIRC we talked about letting it take a URL instead of or in addition to just a Blob, for more general utility. I suggest you bring it up on public-webapps@, where that spec lives. http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver I agree that an API like FileSaver is the right way to do this. Using input type=file wouldn't really fit well because that's more for providing data for upload than providing a file for writing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Current autofill products rely on contextual clues to determine the type of data that should be filled into form elements. Examples of these contextual clues include the name of the input element, the text surrounding it, and placeholder text. We have discussed the shortcomings of these ad hoc approaches with developers of several autofill products, and all have been interested in a solution that would let website authors classify their form fields themselves. While current methods of field classification work in general, for many cases they are unreliable or ambiguous due to the many variations and conventions used by web developers when creating their forms: + Ambiguity: Fields named name can mean a variety of things, including given name, surname, full name, username, or others. Similar confusion can occur among other fields, such as email address and street address. + Internationalization: Recognizing field names and context clues for all the world’s languages is impractical, time-intensive, and error-prone (as good context clues in one language may mean something else in another language) + Unrelated Naming: Due to backend requirements (such as a framework that a developer is working within), developers may be constrained in what they can name their fields. As such, the name of a field may be unrelated from the data it contains. We believe that website authors have strong incentive to facilitate autofill on their forms to help convert users in purchase and registration flows. Additionally, this assists users by streamlining their experience. To that end we would like to propose adding an autocompletetype attribute [1] to the HTML5 specification, as a complement to the existing autocomplete attribute that would eliminate ambiguity from the process of determining input data types. We developed this initial draft proposal working together with developers or several autofill products, and are now looking forward to feedback and suggestions from the broader community. [1] http://wiki.whatwg.org/wiki/Autocompletetype Thanks, ~Ilya Sherman, Chromium Autofill Developer
[whatwg] base elements security issue
On Wed, 11 May 2011, Boris Zbarsky wrote: On 5/11/11 3:28 AM, Henri Sivonen wrote: Not citing specific real site breakage, though. The problem is that Gecko re-resolves existing images when the base URI of the documnet changes. Uh... it does? News to me! On Fri, 13 May 2011, Henri Sivonen wrote: I could be misinterpreting the result, but it looks like it from black-box observation. I can't reproduce that: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1281 Do you have a test showing what you mean? On Tue, 19 Jul 2011, Boris Zbarsky wrote: On 7/19/11 9:12 PM, Ian Hickson wrote: Would other browser vendors be willing to change to only look atbase href inhead? Gecko used to implement that back when the spec said it. This caused site compat issues. See https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin outside the US being broken) and https://bugzilla.mozilla.org/show_bug.cgi?id=592880 (hyperlatex output being broken) for example. The latter explicitly mentions that hyperlatex output is broken in recent IE versions. The former depends on the parsing behavior of IE you describe so is not a problem in IE9-. See https://bugzilla.mozilla.org/show_bug.cgi?id=593807#c7 On the other hand, this change would fix CA Unicenter (https://bugzilla.mozilla.org/show_bug.cgi?id=627361 and its two duplicates), I think. So I guess it comes down to what set of sites we want to break here Do other UA vendors have any data on the matter? Since despite this security risk being known for a few months nobody has rushed to change this behaviour, and all the browsers except IE still seem to honour base in body, I've left the spec as is and just added a warning to the section that talks about XSS. On Tue, 19 Jul 2011, Boris Zbarsky wrote: That said, I'm not sure I understand the security concern. What kind of whitelist-based filter would let through scripts whose URIs it does not control, exactly? On Wed, 20 Jul 2011, Anne van Kesteren wrote: The script is from the page itself and uses a relative URL. The base is inserted by the attacker and causes the script to be requested from a server under the attacker's control. On Tue, 19 Jul 2011, Boris Zbarsky wrote: Can the security concern be mitigated by only allowing base outside head if the base URI it sets is same-origin with the document? That seems a bit overly-complicated, though it would certainly make the issue less serious. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove maxWidth from fillText and strokeText
On Thu, 12 May 2011, Charles Pritchard wrote:
Their intent is to ensure that when you have a specific amount of
space in which text has to fit, and you don't know exactly what that
space is or you don't know exactly what the text is, you can easily
work around minor cases of limited space. For example, I use it on the
issues chart:
There's no guarantee of legibility
There's never any guarantee of anything. However, within reason this can
maintain legibility.
there's no exposure as to the actual size of the font being used.
Indeed typically the text would be squeezed, not made smaler.
It's not (or was not, in the recent past) implemented in many browsers.
IE9, Chrome, Opera, and Firefox all seem to implement it.
It serves only minor cases. It's unnecessary.
It serves pretty much every time you want to put text on a label and are
pretty sure it'll fit, but it might go slightly over.
Yes, you can use TextMetrics. So why have this added bloat?
Convenience. This is a trivial cost for significant convenience.
Most of your philosophy regarding the Canvas API has been to keep out
unnecessary and unimplemented items. I don't see how this one is any
different.
It changes multiple lines of code which most authors wouldn't write into
an additional trivial argument that greatly improves the UI. I think
that's a pretty good deal.
If it were intended, to be more useful, I'd want to see it in
measureText as well, so that measureText('string', maxWidth) would
return a font size attribute.
We'll be improving measureText's metrics in due course.
Your use case, in your data chart, could quite easily have been written
up without the added attribute. That's why I'm bringing this up.
It could have been done, but I probably wouldn't have bothered if it
wasn't an extra argument.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] creating a new file via the File API
It isn't clear to me that a tag question can be addressed by an api answer. Even if there is an api for saving to file, isn't there value to being able to declare your intentions through a tag? The input type=file tag specifies that a user will be able to interact to specify a file through a dialog. There's absolutely no commitment that that file will actually be uploaded or input. That's up to the form or the javascript that handles the input. It seems entirely consistent to be able to permit specification of a brand new file in that dialog that input type=file is already creating. What some javascript _does_ with the specified file might need to be implemented using a filesaver api, but that's separate from the declaration of an interaction for specifying the file. On 12/15/2011 6:45 PM, whatwg-requ...@lists.whatwg.org wrote: On Mon, 15 Aug 2011, David Karger wrote: / // Apologies if I'm revisiting old territory. I've been doing work on pure // html/javascript applications that work entirely clientside // (http://projects.csail.mit.edu/exhibit/Dido). For persistence, they // read and write local files. There's already aninput type=file // interface for letting the user specify a file to be read. And I can use // the same interface, inappropriately, to let the user overwrite a // preexisting file. But things get much messier if I want to let the user // specify a _new_ file to be written, because the file-open dialog doesn't // offer users a way to specify a new filename. What I'd like to be able // to do is specify a tag, or a invoke some javascript method, that will // produce the save file dialog typical of most systems, with a graphical // directory browser but including the option to specify a new filename. // This problem isn't unique to me; a discussion on stackoverflow appears // at // http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file // where the proposed solution is to use flash---and that would be an // unfortunate loss of html5 purity. They also suggest the hack of using a // data: url but that has size limitations. // // Perhapsinput type=file could be given an attribute specifying // whether a new filename is permitted? / On Wed, 7 Sep 2011, Eric U wrote: / // This sounds like a job for the FileSaver interface. Currently no // browser implements it, but we at Chrome have been considering it. At // TPAC last year we discussed it a bit in the WebApps WG meeting; IIRC we // talked about letting it take a URL instead of or in addition to just a // Blob, for more general utility. // // I suggest you bring it up on public-webapps@, where that spec lives. // http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver / I agree that an API like FileSaver is the right way to do this. Using input type=file wouldn't really fit well because that's more for providing data for upload than providing a file for writing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
