Re: [whatwg] Styling details
On 2011-04-08 23:20, Jukka K. Korpela wrote:
Tab Atkins Jr. wrote:
On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Tab Atkins Jr. wrote:
details is definitely something we want to make fully
author-stylable.
I don’t. Who’s this ”we” you are talking about, and why do they want
to make details author-stylable even before a single browser has
_any_ support to the element, at the functional level?
We being, I suspect, the browser community.
Thank you for the clarification. I would prefer seeing _one_ decent
implementatiom of details before considering any fine tuning.
We, Opera, have an internal implementation. Chrome are also working on
their implementation of it in WebKit. We would like our implementations
to be compatible as far as author styling is concerned, and so it is
very useful to discuss the fine-tuning of CSS styling before we ship.
If we did not do this, then you and every other author would most
certainly complain when Opera and Chrome ship incompatible
implementations that require vastly different approaches to styling.
If that's overreaching,
then I'm content to say that *I* want it to be fully author-stylable,
The primary question, as I see it, is to get decent implementations in
the first place. I don’t see crowds of authors yelling for
author-stylability.
Authors have been yelling for author-styling in relation to many other
elements in the past. In particular, fieldset and legend are
paticularly troublesome because their default appearance and the effect
of applying various CSS properties is literally impossible to express
using CSS or XBL right now, and differnet implementations have slightly
different behaviour in some cases. This severely limits what authors
can do with those elements. Authors have also been yelling for more
ability to style form controls.
As far as details elements are concerned, our developer relations team
at Opera have been discussing these new HTML features with the web
developer community for a long time, and styling is absolutely among the
the top concerns that they pass on to us.
Does it? Why do you imply the visual concept of a ”disclosure
triangle”, and how does that relate to the behavior proposed for
”::marker” in some draft?
I don't understand the question.
Why does details need to have any ”disclosure triangle”?
The default appearance needs a disclosure widget of some kind, either a
triangle or plus symbol or whatever. However, since these default
appearances will not suit all needs, it is essential that authors be
able to change this freely in their pages, which is why we need to
discuss the finer details of how the default styling is defined. This
includes defining suitable 'list-style-type' values for the open and
closed states ('disclosure-open' and 'disclosure-closed'), which authors
may override.
However, the default visual behavior of details is suggested in
the HTML spec.
... And I would not take it as more than a suggestion in a work in
progress, which is what it really is.
Yes, it is a suggestion. But as we are now implementing it, we are
trying to ensure that the spec can be made clearer and more accurate.
I know that many CSS property names are misleading. But
list-style-type, as defined in published CSS recommendations, isn’t
bound to any ”::marker”.
It certainly is, in the Lists spec.
Please cite the recommendation by its official name and/or URL.
http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Media elements statistics
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] Styling details
Lachlan Hunt wrote: We would like our implementations to be compatible as far as author styling is concerned, and so it is very useful to discuss the fine-tuning of CSS styling before we ship. If we did not do this, then you and every other author would most certainly complain when Opera and Chrome ship incompatible implementations that require vastly different approaches to styling. No, I would not, and when authors start using details, their first concern is, or should be, whether users will recognize the element's rendering as something that provides optional access to detailed information. This usability issue is crucial and should be tested widely, and we need _different_ implementations in order to be able to evaluate different approaches. Authors have been yelling for author-styling in relation to many other elements in the past. Authors yell a lot. You should care more about usability and other aspects of good design than the sounds of authors who are eager to author-style everything. You can't please everyone. Why does details need to have any ”disclosure triangle”? The default appearance needs a disclosure widget of some kind, either a triangle or plus symbol or whatever. It needs to convey the message of optional availability of additional information and an intuitive way of taking the option. It is far from clear how this could best be achieved. As I wrote, we would need to see some implementations before worrying about how to describe them in CSS terms. When (or if) some reasonable implementation approaches will be found, they will most probably need some new features added to CSS. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. It certainly is, in the Lists spec. Please cite the recommendation by its official name and/or URL. http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement The document says: This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. (Markers were in CSS 2.0, and they were dropped out in CSS 2.1. I'm not very optimistic about seeing them well designed and implemented anytime soon.) -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Recording interface (Re: Peer-to-peer communication, video conferencing, and related topics (2))
Sorry for the top posting, but I would like to reiterate my considered
opinion that Speex be supported for recording. It is the standard
format available from Adobe Flash recording, low bandwidth, open
source and unencumbered, efficient, and it is high quality for its
bandwidth.
On Tue, Mar 29, 2011 at 11:37 PM, Stefan Håkansson LK
stefan.lk.hakans...@ericsson.com wrote:
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
whatwg-requ...@lists.whatwg.org
Sent: den 29 mars 2011 20:33
To: whatwg@lists.whatwg.org
Subject: whatwg Digest, Vol 84, Issue 69
I also believe that the recording interface should be
removed from
this part of the specification; there should be no requirement
that all streams be recordable.
Recording of streams is needed for some use cases unrelated
to video
conferencing, such as recording messages.
Having a recording function is needed in multiple use cases;
I think we all agree on that.
This is mostly a matter of style, which I'm happy to defer on.
The streams should be regarded as a control surface,
not as a data
channel; in many cases, the question of what is the
format of the stream at this point
is literally unanswerable; it may be represented as hardware
states, memory buffers, byte streams, or something
completely different.
Agreed.
Recording any of these requires much more specification
than just
record here.
Could you elaborate on what else needs specifying?
One thing I remember from an API design talk I viewed:
An ability to record to a file means that the file format is
part of your API.
For instance, for audio recording, it's likely that you want
control over whether the resulting file is in Ogg Vorbis
format or in MP3 format; for video, it's likely that you may
want to specify that it will be stored using the VP8 video
codec, the Vorbis audio codec and the Matroska container
format. These desires have to be communicated to the
underlying audio/video engine, so that the proper transforms
can be inserted into the processing stream, and I think they
have to be communicated across this interface; since the
output of these operations is a blob without any inherent
type information, the caller has to already know which format
the media is in.
This is absolutely correct, and it is not only about codecs or
container formats. Maybe you need to supply info like audio
sampling rate, video frame rate, video resolution, ...
There was an input on this already last November:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029069.html
Clearer?
--
Message: 2
Date: Tue, 29 Mar 2011 15:27:58 +0200
From: Wilhelm Joys Andersen wilhel...@opera.com
To: whatwg@lists.whatwg.org
Subject: [whatwg] details, summary and styling
Message-ID: op.vs3w0wvrm3w...@kunnskapet.oslo.osa
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Hi,
I'm currently writing tests in preparation for Opera's implementation
of details and summary. In relation to this, I have a few
questions
about issues that, as far as I can tell, are currently
undefined in the
specification.
The spec says:
If there is no child summary element [of the details element], the
user agent should provide its own legend (e.g. Details). [1]
How exactly should this legend be provided? Should the user agent add
an implied summary element to the DOM, similar to tbody, a
pseudo-element, or a magic non-element behaving differently from both
of the above? In the current WebKit implementation[2], the UA-provided
legend behaves inconsistently from from an author-provided summary
in the following ways:
* Although it can be styled with rules applying to
summary, it does
not respond to :hover or :first-child.
* With regards to text selection, it behaves more like an input
type='submit' than a user-provided summary. Text within this
implied element may only be selected _together_ with the text
preceding and following it.
* A different mouse cursor is used.
This indicates that it is slightly more magic than I would prefer. I
believe a closer resemblance to an ordinary element would be more
convenient for authors - a ::summary pseudo element with Details as
its content() might be the cleanest approach, although that would
require a few more bytes in the author's stylesheet to cater to both
author- and UA-defined summaries:
summary, ::summary {
color: green;
}
Furthermore, the rendering spec says:
The first container is expected to contain at least one line box,
and that line box is expected to contain a disclosure
widget (typically
a triangle), horizontally positioned within the left padding of the
details element. [3]
For user agents aiming to support the suggested default rendering, how
should the disclosure widget be embedded?
Re: [whatwg] Content-Disposition property for a tags
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html A big +1 to the proposal in this thread, to allow specifying Content-Disposition behavior in anchors. a download=filename.txt would have the effect of adding (or overriding) the header Content-Disposition: attachment; filename=filename.txt. It would mean I'd no longer need to use server-side hacks to cause Content-Disposition to be sent for download links, eg. where ?download=1 adds the C-D header. I also just now had to implement a server-side script that receives base64 file data and a filename in parameters, and responds by echoing it back. That's an ugly hack to allow client-side data to be saved to disk, and doesn't work with serverless web apps. This would be fixed, allowing both data: URLs and File API object URLs as download links. There was a related proposal here, but it only covers data URIs; the a download approach is simpler and much more useful. http://lists.w3.org/Archives/Public/uri/2010Feb/0058.html -- Glenn Maynard
[whatwg] DOM mutations, transactions and UndoManager thoughts
I'm working on DOM-based editing tools in my spare time, and have been for several years. I use DOM mutation events to build transactions - objects which let me undo DOM mutations and redo them. There's a strong suggestion that DOM mutation observers should replace DOM mutation events altogether, for performance reasons. I believe a recent discussion on execCommand brought this to light again. Also, Mozilla has a bug on file (https://bugzilla.mozilla.org/show_bug.cgi?id=641821 ) to implement mutation observers which only receive a node ( http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0745.html ). For me, this presents a problem: In order to build undoable and redoable DOM transactions, I need some way of extracting a before and an after state for each individual mutation that happens. For all the ballyhoo about mutation events being evil, this is one thing that they do very well, with prevValue and newValue properties for attribute and data nodes, and with a relatedNode property for node insertions and removals. The proposed mutation observer model does not provide that information. I hope there may be some room to negotiate (either with WHATWG or Mozilla) on the interfaces. Without before and after states exposed through the DOM somehow, I can't make my editor project work, period. --- Now, I was until today unaware of HTML5's UndoManager in section 8.8 ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#undo). Maybe that gets me part of the way there, since it potentially tracks changes to a document. In particular, I note there's no tests or sample JS code for it written yet. I'd like to take a closer look at the interfaces there. For comparison, I'd like to mention Mozilla's nsITransaction interfaces, including nsITransactionManager - one of the nicest ideas for an editor, and one that's worked well for Mozilla's editors, including HTML inputs and textareas, for over ten years. (They're good enough that they've largely escaped attention - very few people think about the interfaces, because the editor's undo mechanism Just Works!) See http://mxr.mozilla.org/mozilla-central/find?text=string=nsITransaction for references. A few thoughts on UndoManager: * First, I really like the add() method. That sounds really useful, especially if it's scriptable, because I see myself having custom transactions which I may want to track through a document's UndoManager. * The title is even more important - it would give people a way to see a localized description of what the transaction is. Though I personally think it should not be a separate value - I think it should be a required property of the undo object. (This is one thing I actually hate about Mozilla's transaction interfaces: they didn't make it easy to label transactions.) * I'm not so sure about the remove() method. Why do we have it? If we allow removing items by index, would we want to have a splice() method that lets scripts insert items at a given index? * Naturally, UndoManager sounds a lot like nsITransactionManager. * I wonder about configuring UndoManager by script. For instance, I really want to turn UndoManager on or off by script. (Most of the time, users won't care about UndoManager, so I would think it would be disabled by default, not actively recording transactions.) Or, I may want to track attribute changes, but not node value changes. * I think a diagram clarifying the flow of actions through UndoManager would be helpful. Is it UndoManager.add(data) - data.doSomething() (which changes the document), or the other way around? How would this affect custom actions being added through UndoManager.add()? * For undo objects added by script, how would the UndoManager tell the scripted undo object to, well, undo something? Or redo something? (In particular, in such a way that the UndoManager doesn't record changes happening while the undo object changes the document in an operation.) * Is it feasible to have an UndoManagerObserver which is notified of undo objects being passed through the UndoManager (either in enabled or disabled state)? That would make it possible to manage undo objects in another context besides the UndoManager (example: I want to export undo objects to a Mozilla transaction manager, so that I drive it from there). * I'm surprised that UndoManager doesn't have a maxlength. Do we really intend to let it undo an infinite number of actions? I hope to open a debate on the UndoManager section, and on undo/redo operations in general, with this e-mail. Alex Vincent San Leandro, CA author, Verbosio XML editor project (in development hell for six years and counting!) -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] Canvas.getContext error handling
getContext doesn't specify error handling. WebGL solves this oddly: if an error occurs, it dispatches an event with error details at the canvas. It's odd for a synchronous API to report error information with an event; it would make a lot more sense to raise an exception. However, getContext doesn't specify error handling for the Return a new object for contextId algorithms. The primary context should only be set by getContext after Return a new object for contextId completes successfully; it shouldn't be set on error. The cached return value used in step 5 should also only happen after success; don't cache a null response. This way, you can retry getContext on failure, and getContext is a straightforward no-op after an error. (I don't know if the WebGL folks could be convinced to change to throwing an exception or if they want to continue returning null and firing an event.) Related thread: https://www.khronos.org/webgl/public-mailing-list/archives/1104/msg00027.html -- Glenn Maynard
