Re: [whatwg] Styling details
On 2011-04-06 03:36, Tab Atkins Jr. wrote:
I like the idea of using display:list-item for thesummary. It has
some unfortunate weaknesses due to the way that display:list-item is
defined; in particular, you can't get an inline summary without losing
the disclosure marker, since there's no way to make an inline
list-item right now.
If authors want to do that now, it's not such a big deal for them to
provide their own disclosure icon as a background image in the padding
area, or to use this in their own styles:
[open]summary::before { content: url(open.png); }
summary::before { content: url(closed.png); }.
I expect this to be fixed on the CSS side in due
time, with the 'display' property split into some subproperties such
that ::marker generation is independent of the list item being inline
or block.
Yes, that will be useful.
I also like the display:transparent idea for handling the wrapper
around the rest of the contents.
:-)
Swapping out bindings (the second solution) feels hacky and bad.
Using a details-specific pseudo-element (the third solution)
doesn't actually solve the problem - it's still a box surrounding the
extra content, so it would suffer from the same problem that was
previous cited, where setting display:table-cell on an element in the
contents wouldn't work as intended. Its only good side is that you
can style the pseudoelement directly, which would make *some*
use-cases salvageable.
Agreed, that's why I said it only provides a workaround, and we are not
taking that approach internally.
Our implementation will be black-box-equivalent to the first two
alternatives, minus the XBL bindings, and our UA stylesheet will be
exactly as I described in the proposed solution.
So either of those approaches should be acceptable, though I do prefer
the more elegant display:transparent; approach.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[whatwg] Request for HTML.next ideas
Note: while this email is intentionally cross-posted; my request is that any responses trim the replies down to *one* of the above lists. === At the present time within the HTML WG, there are no surveys active, and no calls for proposals. Some are actively working on converging to fewer active proposals for issue 152. The editors have some changes to apply before we proceed to Last Call. The chairs still have some surveys and proposals to evaluate. Meanwhile, this may be a good time for others to begin to capture ideas for what comes after HTML5. I know that the WHATWG has ideas for some features and even has some speculative specification text beyond what can make the deadline for HTML5. I doubt the A11y team has exhausted their wish list. At this time, I would like to request that people capture their ideas here: http://www.w3.org/html/wg/wiki/HTML.next Ideas don't need to be fully fleshed out. In fact, in many cases a simple pointer to a proposal or even a discussion hosted elsewhere is all that is needed at this time. There isn't a hard deadline on this request, but we anticipate that the data captured will be discussed at the next AC meeting which goes from the 15th of May to the 17th of May. Thanks! - Sam Ruby
Re: [whatwg] Media elements statistics
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]
[whatwg] Can we make checkboxes readonly?
Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. Radio buttons can't be readonly either, but they have the obvious complication of being multiple elements. We could define behavior for them, of course. One option is to take the @required route, and say that if one radio button in a group is readonly, they all are. We could alternately say that a radio button being readonly means that that specific input can't have its checkedness changed - if it's currently unchecked, clicking on it won't check it; if it's currently checked, clicking on a mutable radio button from the same group wouldn't change the checkedness of either input. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 1:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. As someone who spends a lot of time writing native UIs, I agree. It's useful to be able to dim out a checkbox that no longer applies when some other, related form control is changed. We could alternately say that a radio button being readonly means that that specific input can't have its checkedness changed - if it's currently unchecked, clicking on it won't check it; if it's currently checked, clicking on a mutable radio button from the same group wouldn't change the checkedness of either input. Enabling individual radio buttons within a group to be disabled would match Windows' capabilities, at least. It's not clear whether the right behavior might not be to allow clicks on an enabled button to unselect the disabled button, though. See for example someone wanting that with a Windows native control here: http://social.msdn.microsoft.com/Forums/en-IE/vcmfcatl/thread/75fef4b4-a7ab-4e96-ac9b-12cb27085ab9 PK PK
Re: [whatwg] Can we make checkboxes readonly?
On 2011-04-06 22:45, Tab Atkins Jr. wrote: Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-04-06 22:45, Tab Atkins Jr. wrote: Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
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? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 3:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-04-06 22:45, Tab Atkins Jr. wrote: Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. Also, consistency across input types seems like a good thing for authors. / Jonas
Re: [whatwg] Can we make checkboxes readonly?
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? What are the use cases for readonly on input type=text? I would imagine the use cases for checkbox isn't very different. / Jonas
Re: [whatwg] Can we make checkboxes readonly?
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. ~TJ
Re: [whatwg] Can we make checkboxes readonly?
On 4/6/11 3:43 PM, Jonas Sicking wrote: What are the use cases for readonly oninput type=text? The primary one I've seen is to have a non-editable text input that the user can still select-and-copy from. -Boris
[whatwg] Geolocation - Browser usability issues with regards to asking user permission
I'm building a web-app that makes use of the Geolocation API. While building my application, I've come across an issue with how browser makers have implemented the Geolocation API. Depending on the browser and device, permission will be asked either in a bar across the top of the browser (Firefox and Chrome on the desktop) or with a modal dialog (Safari on the desktop and on the iPhone). At the moment, I don't have access to Chrome on an Android device or access to Internet Explorer on Windows, so I can't tell you how they implement the permissions dialog. As the creator of a site that uses geolocation, these two different implementations of the permissions dialog concerns me. In my tests with users, I've noticed that with Firefox and Chrome, many users don't notice the bar across the top and thus features of the web application end up crippled because the app doesn't have access to the user's location and this degrades the user experience. As a web app developer, I have to either grin and bear this or I need to spend extra development effort to create an absolutely positioned window in the top righthand corner of the screen to call the user's attention to the non-obvious geolocation permission dialog. To do this I also need to browser sniff, since this absolutely positioned element should only appear on browsers where the dialog is less-than-obvious. The way I see it there are three possible solutions forward: 1) As a web app developer, I just deal with this. 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. This isn't ideal either since there are arguments both for and against both solutions. For webapps where most or all users are likely to want to give the app permission for access to the additional features, the non-obtrusive bar provides a worse user experience for the webapp. With my app for example really only has value if we know where the user is located. The user informs my app of their location via the geolocation API or keying it it or they don't use my app at all. In this latter case, I most certainly prefer the browser modal dialog box approach. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. Those apps for which it is not important, can opt for the bar across the top. I'm sure there are other possible solutions, but the state of the implementation insofar as the user experience is concerned needs work. In addressing the privacy aspects of the user experience, we've created a usability issue which needs to be addressed as well. best, Andrew (P.S. I really don't know if this mailing-list was the best place to raise the issues above, but since many engineers from all the browser manufacturers watch this list, I figured it is as good a place as any to raise these points)
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? Tim On 1 March 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote: Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking, particularly from implementers but also from anyone else familiar with the APIs (e.g., someone who's used them in practice): http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD The plan is that this should be merged into the main HTML spec, with a full test suite, by the end of August. Feedback appreciated.
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 4:37 PM, Andrew de Andrade and...@deandrade.com.brwrote: 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. This isn't ideal either since there are arguments both for and against both solutions. Besides the con you mention, I think this is also outside the scope of HTML5. The spec has frequently advised browser vendors on characteristics that must or should be true, e.g. w.r.t. allowing users to manage and delete local storage data in a similar fashion to cookies -- but actually dictating precise bits of UI goes too far. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. Those apps for which it is not important, can opt for the bar across the top. Unfortunately, it is far more common for an author to feel that a particular permission is essential than for the user to feel so. Furthermore, modal dialogs have other usability issues that the browser vendor may wish to avoid, e.g. requiring script on many different tabs to stop. In addressing the privacy aspects of the user experience, we've created a usability issue which needs to be addressed as well. Allowing users to toggle a feature on a per-site basis is not just a privacy issue but in many cases one of general functionality. For example, Chrome includes a click to play feature under a flag that allows users to dynamically control plugin invocation, not for privacy but usability reasons. The browser vendor may have strong UI design goals or interface consistency requirements that dictate how functionality choices are portrayed to the user. As a browser UI developer, I am not willing to cede control over those aspects to the web developer. If users don't notice or understand the geolocation prompts in a particular browser, I think the appropriate response is to provide feedback to the browser vendor that users are not successfully navigating their UI. I would be very interested in the details of your testing, how you determined that users were missing the prompts, and how effective were more generalized methods (than making a floating div as a UI callout) in guiding users (e.g. simply telling users they need to give the site permission to access their location before it will work correctly, showing your UI with a big No permission to access your location; did you tell your browser to allow this?-style banner overlaid, etc.). PK
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 8:04 PM, Peter Kasting pkast...@google.com wrote: Furthermore, modal dialogs have other usability issues that the browser vendor may wish to avoid, e.g. requiring script on many different tabs to stop. Are you thinking of how the prompt, etc. require that the UA pause scripts? That's only required for those old synchronous APIs. A modal prompt for an asynchronous API like this doesn't need to do that. There's also the tendency for modal dialogs to be window-modal, locking the user from using any other tab, but the recent trend towards tab-modal prompts solves that problem. I don't think this is necessary, though. A developer that wants these requests to appear modal can simply dim out the page until the response comes back. That'll push attention to whatever the browser's doing, without his having to care too much about what it is. (If the browser itself also dims the page, as for example Firefox and Opera's prompt() dialogs do, then it'll dim it twice, but that's minor.) -- Glenn Maynard
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 7:37 PM, Andrew de Andrade
and...@deandrade.com.br wrote:
2) The HTML5 specification defines how browsers should implement this
consistently -- either a bar across the top OR modal dialog box, but
not both. This isn't ideal either since there are arguments both for
Right now Firefox 4 allow user to put address bar on bottom of page.
Then the pop up will be at bottom.
(All version of Firefox and SeaMonkey also allow to hide address bar)
If address bar is hidden, Firefox 4 will position the GeoLocation popup
depending on the Tab position.
1. As Firefox USER, I dont want WHATWG to tell Mozilla to stop
allowing customization.
2. As a computer USER, I dont want any modal pop ups in applications.
or in other words, I want to be on control, not the developer
and especially absolutely no control for a web developer.
(please read about CICS programming,
you could write enterprise level on-line applications
in a platform which dont allow any modal screens)
Right now following javascript
function xyz(){
navigator.geolocation.getCurrentPosition(function(position)
{alert(position)});
}
setTimeout(xyz,2000);
will trigger geoLocation after 2 seconds.
A malicious website can use this now to create annoyances for USER.
What I want from browser vendors is make
navigator.geolocation.getCurrentPosition
and navigator.geolocation.watchPosition ONLY callable from a CLICK event.
I thought we all learned lesson from window.open popups
I also wanted browser vendors to provide easy option for user to lie
about their location.
Cheers
Biju
