Re: [whatwg] Can we make checkboxes readonly?
On Apr 6, 2011, at 3:46 PM, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. That's true, but if the controls are readonly, then the user can't change the value and so why does that matter? Could you clarify the use case for having a readonly checkbox value submitted? An app may dynamically set inputs or groups of inputs to readonly based on app state. When you submit, though, it's impossible to tell (without hacks) whether a checkbox was checked-but-disabled or just unchecked. Handling the form data is *much* easier if you just get all the data, regardless of whether, as a UI convenience, your app temporarily set some of the inputs to readonly. In native app UI, it's highly unusual to have a checkbox that is read-only but not disabled. It would be extremely confusing for a checkbox to have the enabled look but not actually be checkable. Therefore, we should not encourage content authors to build UI that looks like that. If you want to dynamically turn some inputs read-only but still submit their values, then presumably you are using script and can add hidden inputs to reflect that state. While this is inconvenient, I don't think it is a good idea to create bad UI solely for convenience. Another possibility is to make read-only checkboxes look and act disabled, with the only difference being whether the value is submitted or not. I have no objection in principle to such a state, but: - readonly seems like a poor name for this state, since in the case of text controls, readonly actually has different user-visible interaction behavior from disabled, not just different submission rules. - The fact that older browsers wouldn't support this special state makes it hard to adopt incrementally. disabled with an extra attribute saying submit anyway would do a better job of degrading gracefully, but would mean that for a while, authors have to do the hidden input trick as fallback anyway. Given these things and the relative obscurity of the use case (UIs where disabling and enabling controls follows a complex pattern are rare and typically not good design anyway), I am not sure the feature is worthwhile. Regards, Maciej
Re: [whatwg] Proposal for a web application descriptor
On Sat, 2011-04-30 at 09:52 -0400, Glenn Maynard wrote: Asking for specific permissions in the context of a user action is the only model that makes sense to me. When applications ask for a big bundle of permissions in advance, how can I as a user know what to do? I'm sure to get into a habit of either blindly denying the permissions (crippling applications), or granting the permissions (terrible for security). While some Mozilla developers may think big bundle of permissions is a good idea, others such as me do not. I'd wonder what their response is to Android; the problems on that platform are obvious. The result is exactly as you say: people end up giving up and just accepting everything. There's also the problem that legitimate permission requests that lack context make people who understand the implications needlessly cautious. For example, some of my friends were suspicious of Firefox for Android wanting access to geolocation. The request for the permission wasn't in the context of an explanation of how Firefox uses that system API to implement the Web geolocation API and has its own authorization UI layer on top of it. (I think asking for a specific permission in the context of a user interaction is better than asking for a bunch of stuff up front.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] questions regarding submit event timing
On Sun, May 1, 2011 at 9:14 PM, Hallvord R M Steen hallv...@gmail.com wrote: 1) What methods exactly cause the scripted submit flag to be set? Load the one-page version (and hope your browser survives): http://www.whatwg.org/specs/web-apps/current-work/ You can search for the text scripted-submit here. The only place in the HTML5 spec itself that sets this flag is submit() (http://www.whatwg.org/specs/web-apps/current-work/#dom-form-submit), although other specs could also use that flag. 2) Is the event fired synchronously? (And is it fired synchronously for all three cases of scripted submits mentioned above?) Again, I think the answer is yes but I couldn't find this information in the spec when looking for it. All events in the HTML5 spec are effectively synchronous; it uses tasks to get the effect of what DOM Events calls an asynchronous event. Step 6 says fire a simple event that is cancelable named submit, at form, which is strictly synchronous; if it was firing it asynchronously it'd say queue a task to fire a simple event. (It's also possible for an entire algorithm to be running from a task, in which case the event is synchronous with respect to the algorithm, but the algorithm itself, including the event, is asynchronous with respect to any script that triggered it. Handling these common but more complicated interactions is why this method is much clearer and more powerful than the overgeneric asynchronous event concept.) -- Glenn Maynard
[whatwg] Spec references in multipage
This is probably a known issue, but the reference lists in the multipage version of the specs only list references within the same section of the spec. Clicking submitted in [1] shows only two references. Clicking the same thing in the single-page version shows nine. It would be very helpful if external references were included. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit -- Glenn Maynard
Re: [whatwg] Submitting form question
On Thu, 30 Dec 2010, yael.aha...@nokia.com wrote: When submitting a form, whose method is GET and action is identical to the current location, except for the fragment, should that trigger reloading the page, or simply navigating to the fragment? The background for my question is in the analysis done in https://bugs.webkit.org/show_bug.cgi?id=20342#c35 On Thu, 30 Dec 2010, Aryeh Gregor wrote: As I'm reading the spec, you're doing Mutate action in step 19 here: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm Then in the navigation algorithm, step 7 says you just navigate to the new fragment and don't reload the page: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate I agree with this analysis. If it is still not clear, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media elements statistics
All, I've updated the wiki with a proposal... http://wiki.whatwg.org/wiki/Video_Metrics#Proposal Cheers! Steve On Sat, Apr 9, 2011 at 7:08 AM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Ah, thanks for the link. I've included Silverlight stats, too, for completeness. If somebody knows about QuickTime stats, that would be another good one to add, I guess. Cheers, Silvia. On Fri, Apr 8, 2011 at 5:21 PM, Jeroen Wijering jer...@longtailvideo.com wrote: On Apr 7, 2011, at 8:11 AM, Silvia Pfeiffer wrote: I've also just added a section with the stats that the Adobe Flash player exposes. Great. Perhaps Silverlight stats might be of use too - though they're fairly similar: http://learn.iis.net/page.aspx/582/advanced-logging-for-iis-70---client-logging/ Apart from the statistics that are not currently available from the HTML5 player, there are stats that are already available, such as currentSrc, currentTime, and all the events which can be turned into hooks for measurement. Yes, the network and ready states are very useful to determine if clients are stalling for buffering etc. I think the page now has a lot of analysis of currently used stats - probably a sufficient amount. All the video publishing sites likely just use a subpart of the ones that Adobe Flash exposes in their analytics. Especially all the separate A/V bytecounts are overkill IMO. One useful metric I didn't list for JW Player but is very nice is Flash's isLive property. Kind regards, Jeroen On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson wats...@netflix.com wrote: All, I added some material to the wiki page based on our experience here at Netflix and based on the metrics defined in MPEG DASH for adaptive streaming. I'd love to here what people think. Statistics about presentation/rendering seem to be covered, but what should also be considered are network performance statistics, which become increasingly difficult to collect from the server when sessions are making use of multiple servers, possibly across multiple CDNs. Another aspect important for performance management is error reporting. Some thoughts on that on the page. ...Mark On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote: On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce ch...@pearce.org.nz wrote: On 1/04/2011 12:22 p.m., Steve Lacey wrote: Chris - in the mozilla stats, I agree on the need for a frame count of frames that actually make it the the screen, but am interested in why we need both presented and painted? Wouldn't just a simple 'presented' (i.e. presented to the user) suffice? We distinguish between painted and presented so we have a measure of the latency in our rendering pipeline. It's more for our benefit as browser developers than for web developers. Yeah, just to be clear, we don't necessarily think that everything in our stats API should be standardized. We should wait and see what authors actually use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] sic element
On Thu, 30 Dec 2010, Martin Janecke wrote: Am 30.12.2010 um 02:47 schrieb Ian Hickson: On Tue, 30 Nov 2010, Martin Janecke wrote: I support this idea and I'd certainly use it. For example, I'm currently copying an old rhyme book to hypertext and would love to mark historically correct (but now incorrect) spelling, spelling intentionally done wrong for better rhyming (yes, people did this in the past) and unintentional errors from the book semantically. I think it is important to note where those errors are done intentional (by me, the publisher of the web page) in contrast to errors accidentally added by me that differ from the copied book. mark is the element for this purpose. I don't think mark is appropriate for what I meant. I as the publisher usually don't mean[1] to point a readers attention at spelling errors by someone I quote, I just want to be able to add semantic markup that identifies a part of text as deliberately published just the way it is published. Here's an example of a webpage quoting the US constitution http://en.wikisource.org/wiki/Constitution_of_the_United_States_of_America#Section_2: The House of Representatives shall chuse their Speaker and other Officers I'd like to be able to code this as The House of Representatives shall sicchuse/sic their Speaker and other Officers to record that I intentionally wrote chuse, not choose, as chuse is exactly what the constitution says. Ah, I see. I misunderstood your original use case; I thought you meant that you wanted to bring these historical artefacts to the reader's attention, not that you wanted to just mark them as intentional. On Fri, 31 Dec 2010, Martin Janecke wrote: I understand the question in this context as a concrete formulation of questions such as What problem(s) does meta data solve? What problem(s) does semantic markup solve? They carry additional information about a text. They solve the problem of not having this information available. Is the additional information worthwhile in this special case? I think so. It's common in plain text ([sic]) and even spoken language. It's found in scientific papers as well as in respected newspapers. This suggests [sic] might be sufficient to solve the problem of not having the information available. In cases where you want to note this but not make it visible to the reader unless they study it carefully, maybe span title=sic.../span would be better than [sic], that also solves the problem of not having the information available. Think of a search engine, which, as one factor of their ranking algorithm, considers orthography and grammar in a page as quality factor. The search engine could be made to ignore (reasonably few) sic-marked errors in such an algorithm; i.e. not let sic-marked errors rank the page lower. Should a search engine have that problem, we can consider it, but if it's just a theoretical problem at the moment it's best not to solve it. What's wrong with The House of Representatives shall chuse [span lang=lasic/span] their Speaker and other Officers? In many cases there's nothing wrong with a visible [sic]. It has successfully been done for decades. And it will be in future. There's also nothing wrong with plain text in general; it has been used successfully for centuries and will be in future. There's nothing wrong with books that use presentation oriented markup either, e.g. italics when emphasizing. They have been printed successfully for centuries and will be in future. What is wrong with Cats [emphasized] are cute animals or span style='text-style:italics'Cats/span are cute animals or span class='emphasized'Cats/span are cute animals instead of emCats/em are cute animals? Well the first is unfamiliar to readers as a typographic style, the second is media-specific and so wouldn't work for e.g. speech synthesis, whereas em would, and the third requires the author to additionally provide some CSS to convey the semantic, which is problematic since the CSS layer is intended to be optional. The plain text string [sic] doesn't indicate where the start of the [sic]ed part of text is. That means it provides less information than sic.../sic. Is this a real problem? Surely most people would easily be able to determine that the scope of [sic] is simply the previous error. [sic] can't be handled with @media and CSS in general. Why is this a problem? [sic] is hardly used in full quotes/transcriptions, although the advantages of using [sic] in short quotes apply to full quotes too. For example, here's a short quote that uses [sic] visibly: http://en.wikipedia.org/wiki/Article_One_of_the_United_States_Constitution#Clause_5:_Speaker_and_other_officers.3B_Impeachment And here's a transcription that doesn't use [sic] in the same place although its publisher considered it important to indicate the correct reproduction of
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 31 Dec 2010, Jonas Sicking wrote:
The thing that makes this different than Google suggest-style UI is
that in the latter case you need a script that continually polls for
more appropriate suggestions and updates the list -- for this kind of
thing we'd probably want to use a direct API, we wouldn't want to have
scripts have to poke at the datalist DOM in real time.
Why not?
The firefox implementation should allow this (though I haven't tried
this myself). Feel free to try it out and let us know how well/poorly it
works.
I just meant that it would be a poor authoring experience. I agree that it
should in theory be possible with the current API; it just seems that if
that's the use case we want to address, we should instead just have
people point to a URL and be done with it:
input type=text autosuggest=/cgi-bin/autocomplete.pl
...or some such.
On Fri, 31 Dec 2010, Jonas Sicking wrote:
I like the idea of bolding the matching parts of the suggestions which
match the typed string. Or at least creating a pseudo-element which
selected the matching substrings such that you could get the behavior
you want using:
input::matching-suggest {
font-weight: bold;
}
Interesting idea (probably more a CSS thing that HTML though, depends on
how we end up specifying widget-specific pseudo-elements).
That aside, I do in general agree that it would be nice to allow markup
inside options. I do wonder if a lot of pages would break if parsing
was changed in such a way.
This has been suggested in the past. Old builds of Mozilla -- I mean,
REALLY old builds of Mozilla, like back in the M3 days, before Mozilla
0.6 -- allowed you to put img in option. We changed that at some
point; I don't recall why but I could guess compat.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 31 Dec 2010, Mounir Lamouri wrote: On 12/31/2010 03:20 AM, Ian Hickson wrote: On Fri, 24 Sep 2010, Mounir Lamouri wrote: I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. I do not understand that the select inside the datalist should not be invalid but why it *has* to be barred from constraint validation? Adding the required attribute to the select element in that case would be stupid and useless. The other way to make the select element invalid would be by calling .setCustomValidity(). Is there a real use case that require calling .setCustomValidity() in batch? Even if, can't we rely on the authors not calling .setCustomValidity() on elements that should not be invalid? We already do that for non-displayed elements, don't we? You should take into account that this requirement force the UA to check the entire parent tree to prevent a situation that can happen in various other ways. select in a datalist is completely ignored for form submission. In fact, any form element at all in datalist is ignored for form submission. See the construct the form data set algorithm: http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set It's so that you can do things like: input ... list=options datalist id=options select ... option.../option /select ...maybe other form controls here... /datalist Basically everything in the datalist except the option elements is for fallback in legacy UAs and is ignored in new UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellcheck API (Re: selection.modify behavior across platforms)
2011/5/2 Hironori Bono (坊野 博典) hb...@google.com: Sorry for my off-the-topic e-mail. I'm interested in spellcheck API these days because web-application developers like to customize the behaviors of the spellchecker integrated in Chrome or use it in their web applications. For example, adding e-mail addresses in a contact list when typing an e-mail address in a To: field, checking the text retrieved via XMLHTTPRequest, etc. If there are those who already work for spellcheck API, I would like to work with them. So, it would be great to give me those who work for spellcheck API. (I wonder if all browsers really need this API, though.) I don't know of any spellcheck API under development, beyond just spellcheck=true/spellcheck=false. There might be one, but I don't recall hearing about it. Some implementers have expressed concerns before about exposing user dictionary data to sites, because it will increase fingerprintability, but other spellcheck features might be useful without causing privacy problems.
Re: [whatwg] textarea newline format - raw value vs. transformed value and setSelectionRange
On Tue, 4 Jan 2011, Michael A. Puls II wrote: But, what happens when pressing ENTER in a textarea? Should it always create a \n in the raw value? What if you paste content that has Line 1\r\nLine 2 in an empty textarea area? Will the raw value contain Line 1\nLine 2 then? I've clarified the spec to indicate explicitly that U+000A is what should be inserted for a line break when the user edits the page. The behaviour when the user pastes a U+000D into a textarea is up to the UA, but could include inserting the U+000D. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Browser inconsistencies in rendering optgroup and option
On Tue, 4 Jan 2011, Boris Zbarsky wrote: On 1/4/11 7:47 PM, Ian Hickson wrote: 1) Gecko makes optgroup and option blocks (and applies some bold/italic/font-size styles to the optgroup, at least). 2) Presto renders the text in theoptgroup (which it treats as an inline) but doesn't render theoption at all. 3) Webkit renders neither theoptgroup nor theoption 4) Trident (IE8/9) renders like Gecko as far as styling the optgroup, except it makes the optgroup and option inlines, not blocks. I have a hard time believing any of this matters for interop, but I think the IE behaviour is closest to what the spec says, technically, though that's mostly because the spec doesn't say much of anything about option andoptgroup rendering and so they just fall back to their defaults. (The spec doesn't even suggest different default font styles, leaving that up to the defaultselect binding.) We can change the spec here if there's a reason to do so, but as you say, I'd be surprised if there were interop needs here, so the simplest behaviour (nothing special) seems the best. Well, the reason Gecko styles optgroup and option as blocks is because it uses CSS layout for the innards of the dropdown in the case of comboboxes and for the list in the case of listboxes. And you really don't want all your options on one line. ;) That makes sense, though I think it'd be better for that to be a style scoped to the binding that defines the select, personally. So we need to either specify that or define some non-CSS thing about how dropdowns and listboxes are actually rendered (esp. because websites very much depend on the details of it!). I would clearly prefer that the behavior be defined in terms of CSS; UAs that under the hood want to ignore the styles and just do something magic can still do that, of course. The behaviour is defined in terms of CSS and a hypothetical binding language similar to XBL; in theory that should be sufficient for your needs, no? If not, I guess we have to work out what we can get browser vendors to converge on. I am concerned that this might not end up being exactly what you need, though, which would be of no more help to you than the status quo, but with more complicated rules. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] link.sizes and [PutForwards=value]
On Wed, 5 Jan 2011, Mounir Lamouri wrote: On 01/05/2011 02:29 AM, Ian Hickson wrote: On Thu, 14 Oct 2010, Olli Pettay wrote: may I wonder why on earth any new API, like link.sizes uses PutForwards? IMHO, PutForwards should be limited to the awkward DOM0 APIs like window.location. On Fri, 15 Oct 2010, Olli Pettay wrote: It makes getters and setters work in a very different way. Inconsistency in APIs isn't a good thing. I don't understand how they work in a different way? The idea is to make the attribute appear to work like a DOMString for most purposes, but to allow methods to be invoked on it. (All the attributes that have [PutForwards] set also have a stringifier on their object's interface.) Is there a use case for [PutForwards] (except saving a few characters for the authors) that could justify the inconsistency? I don't understand how it's inconsistent. Inconsistent with what? The idea is to be consistent with all the other reflecting attributes, which can mostly all be treated as either strings or numbers. Contrast this with the way attributes are reflected in SVG, where there's a step of indirection to get to the string value due to the animation API. I think this is a case where [PutForwards] and stringification makes sense. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Consecutive hyphen-minus characters in comments/in ACE-strings of IDNs
On Fri, 7 Jan 2011, Anne van Kesteren wrote: On Fri, 07 Jan 2011 02:10:26 +0100, Ian Hickson i...@hixie.ch wrote: The question, I guess, is which of the following do we think is more important: * Helping authors not write HTML markup that might be hard to convert to XML, and helping authors avoid nesting comments accidentally, by flagging -- sequences in comments * Getting out of the way of authors who want to put -- sequences in comments, e.g. because they use -- as a long dash (as I do all the time!), or because they want to comment out punycoded URLs. Currently the spec assumes the former is more important. Personally, I think the latter is rather more useful, but then I use -- as long dashes all the time! When this was last studied, the weight of argument was on the stricter disallow -- side of things, presumably. I'm open to changing this back; does anyone else have an opinion on this? I think the main concern back then was compatibility with legacy browsers. I would not mind easing the restriction as relatively soon all browsers will have HTML5 comment parsing. And given that !-- and -- are clear delimiters disallowing -- does not make a whole lot of sense. On Fri, 7 Jan 2011, Henri Sivonen wrote: I'd prefer to keep the cases where infoset coercion has to kick in for valid documents to a minimum. (But I might be optimizing the wrong thing if the larger population doesn't care about infosets.) I've left this as-is for now. I think on the long term it might make sense to change the spec to allow -- in a comment but disallow !--. But let's leave this for now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Input Method Editor API
On Sat, 8 Jan 2011, Ryosuke Niwa wrote: 2011/1/8 Ian Hickson i...@hixie.ch I understand that it might be helpful for pages to contribute data to IMEs, e.g. so that an IME doing text prediction can offer predictions based on words the site knows the user might type (e.g. names from the user's contacts list on the site). However, what's the use case for the page writing its own IME from scratch? Off the top of my head, 1. Users may not have sufficient privileges to install an IME - If I'm going to an internet cafe in the U.S., I wouldn't expect computers to have East Asian IMEs installed. Web page that requires Chinese, Japanese, Korean, etc... can provide suitable IMEs so that users can use it. That helps with those Web pages, but the Web has trillions of pages. It seems rather backwards to be trying to fix the problem with an Internet cafe not having an IME installed by instead trying to put that IME on all the pages the user is going to visit, just in case. Better to fix the Internet cafe. 2. Not all IMEs are free - web page could provide an IME when the client doesn't have one Competing with IMEs at the page level rather than by simply providing a free native IME seems like the wrong solution. 3. Some IMEs are better than others - web page supposedly can provide a better IME. Why not just provide a better native IME? On Sat, 8 Jan 2011, Glenn Maynard wrote: An IME is something you want, consistently, on every page you visit. You don't want every webpage to have a different, inconsistent IME, to have to configure IMEs on each page, etc. OS's without a needed IME installed are an issue, but implementing it in each webpage isn't the right fix. I have to agree with Glenn here. On Tue, 11 Jan 2011, Hironori Bono (˷�� ��ŵ) wrote: Even though my use case are almost the same, I think of another use case: writing an IME used for automated compliance tests. Automated compliance tests can run custom software that have their own IMEs or testing APIs, there's no need for the page to provide one. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Browser inconsistencies in rendering optgroup and option
On 5/2/11 7:26 PM, Ian Hickson wrote: That makes sense, though I think it'd be better for that to be a style scoped to the binding that defines theselect, personally. OK, but more on this below. I would clearly prefer that the behavior be defined in terms of CSS; UAs that under the hood want to ignore the styles and just do something magic can still do that, of course. The behaviour is defined in terms of CSS and a hypothetical binding language similar to XBL; in theory that should be sufficient for your needs, no? I don't think so; we need to define at least some details of the binding. That's what I meant by sites depending on the details. For example, width calculations for select need to work in a particular way (or rather small range of ways) If not, I guess we have to work out what we can get browser vendors to converge on. I am concerned that this might not end up being exactly what you need, though, which would be of no more help to you than the status quo, but with more complicated rules. That's entirely possible, yes. At the moment we're getting bug reports because people write their HTML+CSS, test in only WebKit or only IE, and then it breaks in Gecko. I would assume that there are others who only test in Gecko and then it breaks in other browsers -Boris
Re: [whatwg] link.sizes and [PutForwards=value]
On Mon, May 2, 2011 at 4:37 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Jan 2011, Mounir Lamouri wrote: On 01/05/2011 02:29 AM, Ian Hickson wrote: On Thu, 14 Oct 2010, Olli Pettay wrote: may I wonder why on earth any new API, like link.sizes uses PutForwards? IMHO, PutForwards should be limited to the awkward DOM0 APIs like window.location. On Fri, 15 Oct 2010, Olli Pettay wrote: It makes getters and setters work in a very different way. Inconsistency in APIs isn't a good thing. I don't understand how they work in a different way? The idea is to make the attribute appear to work like a DOMString for most purposes, but to allow methods to be invoked on it. (All the attributes that have [PutForwards] set also have a stringifier on their object's interface.) Is there a use case for [PutForwards] (except saving a few characters for the authors) that could justify the inconsistency? I don't understand how it's inconsistent. Inconsistent with what? The idea is to be consistent with all the other reflecting attributes, which can mostly all be treated as either strings or numbers. Contrast this with the way attributes are reflected in SVG, where there's a step of indirection to get to the string value due to the animation API. I think this is a case where [PutForwards] and stringification makes sense. It's inconsistent in that all other objects in javascript stringify to [Object Foo], whereas this object doesn't. If the concern is that link.sizes should be consistent with other attribute-mapping properties then you're only half-way there since typeof tests still behaves differently. I definitely agree that the way SVG does it is not ideal. How about simply creating a second property, like link.parsedSizes which returns the tokenlist? / Jonas
Re: [whatwg] link.sizes and [PutForwards=value]
On Mon, May 2, 2011 at 5:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, May 2, 2011 at 4:37 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Jan 2011, Mounir Lamouri wrote: On 01/05/2011 02:29 AM, Ian Hickson wrote: On Thu, 14 Oct 2010, Olli Pettay wrote: may I wonder why on earth any new API, like link.sizes uses PutForwards? IMHO, PutForwards should be limited to the awkward DOM0 APIs like window.location. On Fri, 15 Oct 2010, Olli Pettay wrote: It makes getters and setters work in a very different way. Inconsistency in APIs isn't a good thing. I don't understand how they work in a different way? The idea is to make the attribute appear to work like a DOMString for most purposes, but to allow methods to be invoked on it. (All the attributes that have [PutForwards] set also have a stringifier on their object's interface.) Is there a use case for [PutForwards] (except saving a few characters for the authors) that could justify the inconsistency? I don't understand how it's inconsistent. Inconsistent with what? The idea is to be consistent with all the other reflecting attributes, which can mostly all be treated as either strings or numbers. Contrast this with the way attributes are reflected in SVG, where there's a step of indirection to get to the string value due to the animation API. I think this is a case where [PutForwards] and stringification makes sense. It's inconsistent in that all other objects in javascript stringify to [Object Foo], whereas this object doesn't. If the concern is that link.sizes should be consistent with other attribute-mapping properties then you're only half-way there since typeof tests still behaves differently. I definitely agree that the way SVG does it is not ideal. How about simply creating a second property, like link.parsedSizes which returns the tokenlist? Of course, an even simpler solution is to remove access to a DOMTokenList representing link.sizes entirely. What is the use case? Is it really that common to modify link.sizes that we need syntax sugar for it? / Jonas
Re: [whatwg] textarea newline format - raw value vs. transformed value and setSelectionRange
On Mon, 02 May 2011 19:21:26 -0400, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Jan 2011, Michael A. Puls II wrote: But, what happens when pressing ENTER in a textarea? Should it always create a \n in the raw value? What if you paste content that has Line 1\r\nLine 2 in an empty textarea area? Will the raw value contain Line 1\nLine 2 then? I've clarified the spec to indicate explicitly that U+000A is what should be inserted for a line break when the user edits the page. The behaviour when the user pastes a U+000D into a textarea is up to the UA, but could include inserting the U+000D. Thanks -- Michael
