Re: [whatwg] input type=number for year input
On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] input type=number for year input
On 2/18/14, 17:55, Mike Taylor wrote: On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv (for ports under , that is) -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] [canvas] Proposal for supportsContext
On Mon, 10 Sep 2012 13:14:30 -0500, Dean Jackson d...@apple.com wrote: To give a real world example, the popular tool Modernizr tests for the availability of WebGL by attempting to create a WebGL context. This can happen even on pages that have no intention of using WebGL - an author has just inserted Modernizr into their page and is using it to test for another feature. As I said, creating a context is not a free operation. In fact, on shipping Safari (Mountain Lion) this causes us to switch to a more powerful GPU on systems that have two graphics processors. An alternative (for the WebGL case) would be to have the author test for the presence of window.WebGLRenderingContext. However, this is not reliable. This is actually what Modernizr does these days [1], but older versions did in fact create the context. [1] https://github.com/Modernizr/Modernizr/blob/master/modernizr.js#L429-436 -- Mike Taylor Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox m...@matthewwilcox.com wrote: What's the actual WHATWG proscribed format for conducting conversations in email format? See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F -- Mike Taylor Opera Software
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox m...@matthewwilcox.com wrote: , will cause their users to get more broken pages (which is what happens in many cases with browser sniffing right now), will lock new devices out of the market (which is what happens with new UA strings right now). And hence that the proposal is bad for the web in various ways. I'm not sure what your grounds are for thinking this. Would it not be sensible for the server to have to serve some default if the headers aren't there anyway, the assumption must be that the device can't send these headers. In what circumstances might this cause breakages? And how could it possibly lock out any devices? This is a progressive-enhancement type tech, not a if you don't have the ability to notify the server you can't get any info type tech. Surely? Progressive-enhancement type tech gets abused as well. Take the video element, with its lovely source elements for codecs and fallback content for non-supporting UAs. No hacks necessary. Then throw laziness and javascript at it and you've got a mess. An example, visit http://www.maerskfleet.com/ with an empty UA string (or use Opera). In a browser that should be able to support video, you'll get a JS error and the page is blank. Even after including Modernizr and using HTML5 which is designed to gracefully degrade for older UAs, developers do the same old UA sniffing trick: https://gist.github.com/1761168 I would love to believe that all developers would use this proposal for good, as it were. Experience leads me to believe it will be just another technique sniffed and served to the regular suspects. -- Mike Taylor Opera Software
Re: [whatwg] Cut and paste (and related) events' futures
Hi Chris, On Thu, 26 Jan 2012 20:27:41 -0600, Chris O'Brien accou...@prettycode.org wrote: In all the last-released versions of the major browsers (except Opera), there's support for cut-and-paste events like onpaste on input type=text... and textarea elements. Is there any plan to put these events into the standard? Isn't that a basic tenent of WHATWG--if the real-world vendor implementations are in consensus yet don't reflect the standard, change (or add to) the standard to reflect the de facto market standard, so long as any modifications are backwards compatible? You're probably looking for this: http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for clipboard data API in the archives might bring up some interesting discussion as well. Cheers, -- Mike Taylor Opera Software
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 11:52 AM, Philip Jägenstedt phil...@opera.comwrote:
On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther hasat...@gmail.com
wrote:
It would be more useful if the DOMTokenList methods (contains, add,
remove, toggle) would take a space separated list of tokens. This is
the behavior most DOM libraries have when dealing with class names.
So, when setting two classes, instead of
ele.classList.add(hey);
ele.classList.add(ho);
you could do
ele.classList.add(hey ho);
Currently, the latter results in an INVALID_CHARACTER_ERR.
The behavior of all methods should be obvious I guess.
+1, but what should toggle return?
toggle(a) returns true if a was added, which is equivalent to
!contains(a) on the initial string or contains(a) on the final string.
For toggle(a b), !contains(a b) on the initial string may not be the
same as contains(a b) on the final string, so which should it be? Put
simpler, should it return true if any token is added or if all tokens are
added?
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
Same for the rest of the DOMTokenList methods, as well.
foo.add('bar').remove('baz');
See also https://github.com/jquery/standards/issues/13 for relevant
discussion.
Re: [whatwg] Giving the body tag a new meaning.
On 3/1/11 1:54 PM, usuario wrote: According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. Why not propose a better definition then?
Re: [whatwg] validationMessage
On 2/12/10 9:23 AM, Tab Atkins Jr. wrote: On Thu, Feb 11, 2010 at 9:29 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: Do you know of any actual authors who would want to use validationMessage? If there are any authors here who would want to use the validation API with their own UI, would you want to use validationMessage or write your own messages? I wouldn't be likely to write my own UI at all, so I'm not the best person to have an opinion here. When I use a jQuery validation plugin for my forms today, I pretty much always rely on the default error message that the library provides. It's rare for me to override it; I typically only provide messages when I'm specifying a custom validation that doesn't have a message (as the default error message for a custom validation rule is far too generic). So yes, I'd use validationMessage in my own UI. It's easier, as it lets me be completely agnostic about the actual error, and just plug in whatever the error is into my custom UI. I also use a jQuery validation plugin at work--but have a mixture of default and custom errors--depending on what language the business is testing that week. Either way, I do think that validationMessage is absolutely useful. In the cases where I might need to change the message, I'm OK with a mixture of setCustomValidity and using the title attribute in conjuction with the pattern attribute to describe what went wrong (which is how Opera currently works, at least). Mike
Re: [whatwg] Inconsistent behavior for empty-string URLs
Shouldn't this proposal take into account the CSS3 content property? (
http://www.w3.org/TR/css3-content/)
E.g., figure[alt] { content: attr(href, url), attr(alt); }
This was discussed not too long ago, starting in this thread:
Adding a src attribute to all elements (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023955.html
)
-Mike
On Tue, Dec 15, 2009 at 8:37 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:
Yes, that sounds right.
-Nicholas
__
Commander Lock: Damnit Morpheus, not everyone believes what you
believe!
Morpheus: My beliefs do not require them to.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, December 15, 2009 5:22 PM
To: Nicholas Zakas
Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon
Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Here's what I would propose:
1. Empty string attributes for HTML elements specifying resources to
automatically download are considered invalid and don't cause a
request
to be sent. Examples: img, link, script, iframe, etc. This
would
not apply to a href= because it is a user-initiated request.
2. This also applies to manipulation of HTML elements through the DOM,
so (new Image()).src= would not result in a request being sent.
3. This does not apply to JavaScript APIs that are unrelated to HTML
elements, such as Web Workers, XMLHttpRequest, etc.
I'd prefer to explicitly enumerate the elements we're talking about,
rather than giving rules which risk being interpreted differently by
different people.
For example not all links are automatically downloaded, such as
link rel=prev. However I suspect that we'll want all links to
behave the same.
So the specific list would then be:
img
link
script
iframe
video
audio
object
embed
source
input type=image
All of these would never attempt to fetch a resource if the src/href
attribute is empty (even if the current baseuri is different from the
document uri). However it would not act as if the attribute was not
set (important for script).
Does that sound right?
/ Jonas
Re: [whatwg] value content attribute of input
It's not clear to me that every possible attribute is intended to be in that table. Autofocus, for example, is missing as well. However, the first time I read through that table I did do a double-take. Mike T. On Thu, Dec 3, 2009 at 1:48 AM, Futomi Hatano i...@html5.jp wrote: Hi all Could you please see the section in the spec? http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element There is a table which includes summarizes which of content attributes, IDL attributes, methods, and events apply to each state. Is the value content attribute needed to include to the table, isn't it? -- Futomi Hatano www.html5.jp
Re: [whatwg] elemen.onFocus instead of window.onhashcange ?
PS: Please ease on the JavaScripting on the WHATWG version of the spec. I've got a quite old computer and Firefox freezes on me when I visit that page too often. Is all of that needed? Or don't old UAs matter to such an backwards compatible spec? Are you aware of the multi-page spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/)? The single page version will bring any browser to its knees. Cheers, Mike
