[whatwg] [mimesniff] More issues on the MIME Sniffing spec
I want to respond to the following issues in the MIME Sniffing spec: Resources I suggest the following wording for the issue box starting with A resource is... A resource is a data item or message, such as a file or an HTTP response. I believe this covers the cases that would normally be associated with a MIME type. Contexts I don't think the word context needs to be specially defined. The start of section 8 could be rewritten to remove the definition: [[ In certain cases, it is only useful to identify resources that belong to a certain subset of MIME types. In these cases, it is appropriate to use a context-specific sniffing algorithm in place of the MIME type sniffing algorithm in order to determine the sniffed MIME type of a resource. This specification defines the following context-specific sniffing algorithms. ]] Apache Bug As for the Apache bug flag, would it be useful to additionally check the HTTP headers for a Server header and check if it contains Apache/? I don't know which version of Apache the bug involved was fixed in, so I can't suggest a more accurate string check. MP3 Sniffing Finally, the Firefox team has recently included a patch to support sniffing MP3 files better [1] and would like to document it and add it to the MIME Sniffing spec. [2] The disadvantage, though, is that more than 512 bytes are required for an accurate detection. --Peter [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=862088 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=879429
Re: [whatwg] [mimesniff] More issues on the MIME Sniffing spec
On Thu, Jun 6, 2013 at 5:42 AM, Peter Occil pocci...@gmail.com wrote: I want to respond to the following issues in the MIME Sniffing spec: Resources I suggest the following wording for the issue box starting with A resource is... A resource is a data item or message, such as a file or an HTTP response. I believe this covers the cases that would normally be associated with a MIME type. I already have an idea about how to define resource. The reason it's not currently in the spec is because I recall Hixie expressing some concern about complexity beyond bag of bits and I'm waiting on feedback from him. Contexts I don't think the word context needs to be specially defined. The start of section 8 could be rewritten to remove the definition: [[ In certain cases, it is only useful to identify resources that belong to a certain subset of MIME types. In these cases, it is appropriate to use a context-specific sniffing algorithm in place of the MIME type sniffing algorithm in order to determine the sniffed MIME type of a resource. This specification defines the following context-specific sniffing algorithms. ]] On the contrary, I think it may be important to define context, as it is the only lens through which to see fetching and sniffing and the like. Currently, the HTML spec only defines (nested) browsing context, so I put together a wiki page that lists all the other ones that exist implicitly: http://wiki.whatwg.org/wiki/Contexts I plan to rewrite the whole second half of the spec to be in terms of contexts soon. Apache Bug As for the Apache bug flag, would it be useful to additionally check the HTTP headers for a Server header and check if it contains Apache/? I don't know which version of Apache the bug involved was fixed in, so I can't suggest a more accurate string check. That thought had crossed my mind, but the handling of the situation mostly predates my editing of the spec, so I haven't given much thought into whether the current method is the ideal one. MP3 Sniffing Finally, the Firefox team has recently included a patch to support sniffing MP3 files better [1] and would like to document it and add it to the MIME Sniffing spec. [2] The disadvantage, though, is that more than 512 bytes are required for an accurate detection. --Peter [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=862088 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=879429 I'm aware of this. I was told that a proposal would be made in due course, so I'm waiting on that. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] inputmode attribute
On Wed, 29 May 2013, Takayoshi Kochi (河�~F~E �~Z~F��~A) wrote: We work on W3C IME API (http://www.w3.org/TR/ime-api/) and we got comment from Microsoft people that it would be nice to have inputmode attribute in conjunction with the API. Currently the inputmode attribute is spec'ed as http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute But the mode looks somewhat sparse. In the Microsoft's proposal, more modalities are populated: https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#inputmode-attribute Can we discuss the change here to get this proposal merged to the spec? I'm happy to add more values to inputmode= if they correspond to actual input modalities in real products (e.g. iOS, Windows, or Android). What are the values being proposed, exactly, and what modalities to they correspond to? On Wed, 29 May 2013, Mounir Lamouri wrote: A couple of months ago I sent some feedback regarding inputmode [1] I apologise for not having yet processed this feedback (I've been mostly focusing on the bugs these past few months; I hope to get back to e-mails soonish). I'll look at it momentarily. based on your reply [2] I assumed that you agreed that we should probably differentiate inputmode and scripts. However, I see that the IME API isn't making this difference and creates a lot of inputmode values to be able to handle different scripts. Is there a specific reason why or is this just in order to follow the HTML specification? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038947.html On Fri, 31 May 2013, Takayoshi Kochi (河�~F~E �~Z~F��~A) wrote: I'd hope people from Microsoft join this discussion, but from our perspective we agree that we would like to go with mode and script separately. If everyone wants them split, and that's what gets implemented, then that's what should be specced, too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Wed, 13 Feb 2013, Mounir Lamouri wrote: To begin with, I think we should get rid of the latin prefix. The three modes with that prefix are latin, latin-name and latin-prose (Also full-width-latin.) but in none of those situations latin is mandatory. While I think it's appealing, from an abstract perspective, to view the script and mode as orthogonal here, it seems to me that in reality keyboard combine them into a single UI. I fear that separating them would lead to a lot of meaningless combinations being possible. In general, though, this is not my area of expertise and I'm happy to defer to whatever is implemented (as with anything else). (I looked at iOS and Android and considered just mapping all the values to HTML keywords, but that would have made the actual list even more complex, so I just hit the highlights.) Mozilla's implementation also includes 'uppercase' which is a common use case in the web and could be interesting but it isn't as important as other types so it can be kept aside for later. The priority for us here being to make the Web Platform competitive with native apps on Mobile. What's the difference between these two, and why is digit a better name for it than numeric? Finally, it is not clear why 'tel', 'email' and 'url' are available. Mostly it's for letting people build custom UIs (e.g. a Web component that implements type=tel). On Fri, 15 Feb 2013, Jonas Sicking wrote: Using semantic names might give us the warm fuzzies, but is there really any semantic use we will get out of these that we wouldn't by using lowercase, titlecase or autocapitalized? The reason I used the more semantic names is that the names like lowercase, titlecase or autocapitalized aren't accurate. For example, you can hit shift in lowercase mode to get uppercase. You can have a titlecase mode that doesn't capitalise every word (e.g. it recognises the van in van Kesteren). A value that is explicitly for names can use a different dictionary than one that is just for capitalised text (e.g. derived from the user's contact list). And so on. I take it verbatim and name would disable any spelling corrections, and name would also titlecase? But the difference between text and prose seems really hard to understand. In the spec, verbatim does not correction at all, e.g. passwords; latin is for human-to-computer communications, e.g. free-form text search fields, and would do spelling correction and automatically inserting spaces between words in swiping keyboards, etc; and latin-prose is intended for human-to-human communications, with aggressive automatic typing correction, e.g. text prediction and automatic capitalisation at the start of sentences. On Fri, 1 Mar 2013, Mounir Lamouri wrote: People may want to control IME input mode like the way Flash can, http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html but it it is unfortunate that controlling IME from web apps is so distributed (CSS, input attribute, DOM lv3 compositionevent and IME API). As I see it @inputmode isn't here to be a feature like this but maybe Hixie had a different vision when he wrote the specs for it. inputmode= is mainly intended to control what keyboard to use on mobile devices. Maybe if it was named @inputhint and the user was allowed to change the input mode, it would be clearer? Everything in HTML is a hint. The user's always in control. I haven't changed the spec for now, but as noted above, I don't a priori object to making changes, even radical changes, to this part of the spec, if they make sense. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
