Re: [whatwg] WF2: Non-validating submit buttons
2007/4/4, Martin Atkins: * For cancel buttons where the server-side app just throws the submitted form data away, it's pointless to validate it client-side. Attach the cancel button to a distinct 'form' (eventually having the same 'action' and 'method'). * Allowing the user to submit an unfinished form to the server to be saved for later completion. * A preview button that allows the user to see the results of what has been completed so far without completing the entire form. * Buttons that trigger round-trips to the server to alter the form in some way. Those are really good use cases (imo). All three might a priori be achieved using a second 'form' with some javascript to turn every non-validating control to a valid state, and attaching every control to both forms, but that's really tricky, compared to a 'causesvalidation' attribute (I chose 'causesvalidation' because that's the name of the property used in ASP.NET to achieve the same behavior). I'd personally allow such an attribute on both submit buttons and forms (because controls can be attached to multiple forms, it makes sense that validation is triggered depending on the submitting form, not only on which button has been clicked, which might not always be the case: form submitted by javascript). My 2 c€nts -- Thomas Broyer
Re: [whatwg] Apple Proposal for Timed Media Elements
I understand that some here have reasons not to be happy with SMIL, but its implementation within SVG really is quite nice and understandable. So far as I can see, the discontent with it stems primarily from the fact SMIL seems to have alternative specifications. Since the SVG implementation is the one which seems to have met with fairly wide adoption, why not just converge with the attribute set used there to control an animation? Instead of media-loop-count it uses repeatCount. dur controls the duration, begin controls when it starts, end controls when it stops. Just for fun, one can add things like begin=object.click or begin=M.begin+1 to allow control to be passed declaratively, and to synchronize multiple events, hence avoiding the need for copious script. If one had multiple media elements on a page, controlling the synchronization of those elements is quite within the province of SMIL(SVG). All the timing mechanisms that are discussed here, are I believe, covered in SMIL, each with a different set of attribute names. It even has spline interpolations on the timing elements. In Opera or IE with the Adobe plugin http://srufaculty.sru.edu/david.dailey/svg/smil.htm shows some of the range of extant behavior. Sorry if this horse is already dead, and copious apologies about my cluelessness when it comes to how to read and write specifications, but there are already authors and developers who are fluent in SVG/SMIL, so why reinvent wheels? respecfully, David - Original Message - From: Maciej Stachowiak [EMAIL PROTECTED] To: Vladimir Vukicevic [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 10:58 PM Subject: Re: [whatwg] Apple Proposal for Timed Media Elements On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote: Maciej Stachowiak wrote: CSS Timed Media Module proposal - http://webkit.org/specs/ Timed_Media_CSS.html Some feedback on my initial reading.. the CSS properties specified seem like a good set that will cover most common functionality. Some comments about the spec, though: Thanks for reading over this part. 1. 'media-loop-count' is an awkward name, especially with The default value of 1 means the item will play through once but will not loop. We went through this with APNG, and ended up renaming that member. I would suggest 'media-play-count' instead -- that way there is no ambiguity with what the number means. We considered 'media-repeat-count' instead of 'media-loop-count', but that turned out to be more confusing. We really wanted all the looping-related properties to have consistent naming, and I don't think 'play' would work in the other places mentioned. 2. The descriptions for 'media-loop-start-time' and 'media-loop-end- time' don't match; start-time says sets the time at which the media item begins playing after looping, and end-time says sets the time at which the media item loops for the second and subsequent repetitions. I would suggest that start-time says sets the time index at which the media item starts playing for the second and subsequent repetitions, and that end-time says sets the time index at which the media item ends playing for the second and subsequent repetitions. The language for end-time is still a little awkward, since ends playing could imply that it simply stops playing (and does not loop), but it's clearer than before. I think the language might have ended up actually defining it wrong. The intent of 'media-loop-end-time' is that this is the point where you end where repeating, but on the last iteration you go all the way to 'media-end-time'. So if 'media-loop-count' has a value of 3, the three repetitions would go as follows: media-start-time=== media- loop-end-time media-loop-start-time === media- loop-end-time media-loop-start- time === media-end-time I'll update the spec. 3. 'media-timing' I would get rid of completely; while a shorthand would be useful, I don't think that media-timing as specified really works. Shorthands for properties such as 'background' are understandable on their own; 'media-timing: playing 0s -0.5s 2 2s -4s 1' is very opaque. If it's still desirable, I would remove the setting of start/end times and change the volume shorthand to only accept the symbolic names; e.g. 'media-timing: playing high 4;'... but I think that removing the shorthand entirely would be preferable. I'll reply in more detail about media-timing in a later message. Regards, Maciej
Re: [whatwg] Accessibility and the Apple Proposal for Timed Media Elements
Benjamin - On Apr 4, 2007, at 11:44 PM, Benjamin Hawkes-Lewis wrote: Re: http://webkit.org/specs/HTML_Timed_Media_Elements.html There are three things I'd hope to see from a video element: 1) Ease of use compared to object (A common API contributes to this, and v2 might approach it with a default UI. Lack of agreement on a baseline format is a major problem here.) 2) Experiments in hyperfilm. 3) Better accessibility features than are provided by the current object or embed + plugin architecture. We are actively discussing accessibility features internally, and should have something to propose to this group shortly. eric
[whatwg] Trailing garbage, numbers and conformance
Common microsyntaxes for numbers allow leading whitespace and allow trailing garbage. I understand why the algorithms for UAs other than conformance checkers might be defined not to fail when there is trailing garbage. However, to help authors catch typos, I think only trailing whitespace should be conforming not just any trailing garbage. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] tbody content model should be 0+ trs
Why does tbody require one or more tr elements, as opposed to zero or more? http://www.whatwg.org/demos/repeat-01/ has an empty tbody if you click Remove. -- Simon Pieters
Re: [whatwg] tbody content model should be 0+ trs
On Thu, 05 Apr 2007 15:41:21 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Why does tbody require one or more tr elements, as opposed to zero or more? http://www.whatwg.org/demos/repeat-01/ has an empty tbody if you click Remove. Also... since tables are allowed to have trs as direct children of table, if tbody is allowed to be empty then presumably table should be allowed to contain no tbody and no tr elements. -- Simon Pieters
[whatwg] Sequential List Proposal
Following the discussion about the limitations of dialog, I meditated about it a little and came up with the idea to generalize things a little more. When we have a dialog intermixed with actions and other events (like ABC leaves the chat room), basically we have a sequential list of events, actions and spoken parts. And in my later example, the Canadian Parliament hansard, they're intermixed with timestamps at regular intervals and other notes regarding live translations. Again, this fits very well the concept of a list of different kinds of intermixed sequential events. So I propose a sl element (sequential list) which can be used to replace dialog as well as other things. The proposal can be found here: http://www.michelf.com/documents/whatwg/timeline/ Basically, dt and dd work just like they do in dialog currently, except that you can have more than one dd following a dt. li is used for listing events other than speech and time is used to insert time marks where appropriate. And you don't need to have any spoken part, meaning you can use it for system logs, or historical timelines too by using only li and time. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Sequential List Proposal
Le 2007-04-05 à 10:36, Simon Pieters a écrit : I get a 404 for this URI. Oops... sorry. http://www.michelf.com/documents/whatwg/sequential-list/ Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Apple Proposal for Timed Media Elements
On Apr 5, 2007, at 4:53 AM, ddailey wrote: I understand that some here have reasons not to be happy with SMIL, but its implementation within SVG really is quite nice and understandable. So far as I can see, the discontent with it stems primarily from the fact SMIL seems to have alternative specifications. Since the SVG implementation is the one which seems to have met with fairly wide adoption, why not just converge with the attribute set used there to control an animation? Vlad's message is about Apple's proposed CSS properties, not DOM attributes. SMIL is in the markup and so gives you no way to separate presentation from content. The CSS properties would let you separate time presentation of a video or audio element, or in theory an img showing an animated image format or any other element that could be interpreted as showing timed media. So I don't think this competes directly with SMIL. Regards, Maciej
Re: [whatwg] Apple Proposal for Timed Media Elements
Okay -- I guess that makes sense. thanks. David - Original Message - From: Maciej Stachowiak [EMAIL PROTECTED] To: ddailey [EMAIL PROTECTED] Cc: Vladimir Vukicevic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 05, 2007 12:57 PM Subject: Re: [whatwg] Apple Proposal for Timed Media Elements On Apr 5, 2007, at 4:53 AM, ddailey wrote: I understand that some here have reasons not to be happy with SMIL, but its implementation within SVG really is quite nice and understandable. So far as I can see, the discontent with it stems primarily from the fact SMIL seems to have alternative specifications. Since the SVG implementation is the one which seems to have met with fairly wide adoption, why not just converge with the attribute set used there to control an animation? Vlad's message is about Apple's proposed CSS properties, not DOM attributes. SMIL is in the markup and so gives you no way to separate presentation from content. The CSS properties would let you separate time presentation of a video or audio element, or in theory an img showing an animated image format or any other element that could be interpreted as showing timed media. So I don't think this competes directly with SMIL. Regards, Maciej
Re: [whatwg] Apple Proposal for Timed Media Elements
Maciej Stachowiak wrote: On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote: 1. 'media-loop-count' is an awkward name, especially with The default value of 1 means the item will play through once but will not loop. We went through this with APNG, and ended up renaming that member. I would suggest 'media-play-count' instead -- that way there is no ambiguity with what the number means. We considered 'media-repeat-count' instead of 'media-loop-count', but that turned out to be more confusing. We really wanted all the looping-related properties to have consistent naming, and I don't think 'play' would work in the other places mentioned. The problem is that 'media-loop-count' with a value of 1, as defined, doesn't have anything to do with looping... play-count is much more descriptive of its actual purpose, IMO, despite not containing 'loop' in the name. The others should definitely stay loop-, though. 2. The descriptions for 'media-loop-start-time' and 'media-loop-end- time' don't match; start-time says sets the time at which the media item begins playing after looping, and end-time says sets the time at which the media item loops for the second and subsequent repetitions. I would suggest that start-time says sets the time index at which the media item starts playing for the second and subsequent repetitions, and that end-time says sets the time index at which the media item ends playing for the second and subsequent repetitions. The language for end-time is still a little awkward, since ends playing could imply that it simply stops playing (and does not loop), but it's clearer than before. I think the language might have ended up actually defining it wrong. The intent of 'media-loop-end-time' is that this is the point where you end where repeating, but on the last iteration you go all the way to 'media-end-time'. So if 'media-loop-count' has a value of 3, the three repetitions would go as follows: [...] Hmmm. I see how that would be useful, ok. So if I just wanted to loop the first 5 seconds of a video clip, I would just set media-start-time to 0s and media-end-time to 5s, and the count to infinite, right? Clarifying this (perhaps with some examples) would be good. 3. 'media-timing' I would get rid of completely; while a shorthand would be useful, I don't think that media-timing as specified really works. Shorthands for properties such as 'background' are understandable on their own; 'media-timing: playing 0s -0.5s 2 2s -4s 1' is very opaque.If it's still desirable, I would remove the setting of start/end times and change the volume shorthand to only accept the symbolic names; e.g. 'media-timing: playing high 4;'... but I think that removing the shorthand entirely would be preferable. I'll reply in more detail about media-timing in a later message. Sounds good. - Vlad
Re: [whatwg] Trailing garbage, numbers and conformance
On Apr 5, 2007, at 20:44, Ian Hickson wrote: The conformance requirements require the strings to be (e.g. in the case of floating point numbers) valid floating point number, which doesn't allow any spaces or non-numeric data, trailing or leading. Oops. Sorry. Somehow I managed to miss that. Thanks. I like forbidding surrounding whitespace, so I'm not complaining, but I am mildly amused how this makes XSD datatypes even less applicable than previously thought. This leaves the regexp feature of XSD datatypes as the only feature that is useful for HTML5 conformance checking. (And even the definition of the XSD regexps is – how would I put it – less than great.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Apple Proposal for Timed Media Elements
On 4/5/07, Vladimir Vukicevic [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote: 1. 'media-loop-count' is an awkward name, especially with The default value of 1 means the item will play through once but will not loop. We went through this with APNG, and ended up renaming that member. I would suggest 'media-play-count' instead -- that way there is no ambiguity with what the number means. We considered 'media-repeat-count' instead of 'media-loop-count', but that turned out to be more confusing. We really wanted all the looping-related properties to have consistent naming, and I don't think 'play' would work in the other places mentioned. The problem is that 'media-loop-count' with a value of 1, as defined, doesn't have anything to do with looping... play-count is much more descriptive of its actual purpose, IMO, despite not containing 'loop' in the name. The others should definitely stay loop-, though. I agree. To me, a loop-count of 1 means that it will play once and then loop once. If a loop-count of 1 means that it only plays once, then it's not really a loop-count. It's a play-count. I myself like how the Windows Media 6.4 API does it. It has a PlayCount that specifies how many times to play, but 0 is a valid value that means to repeat forever. -- Michael
Re: [whatwg] Default (informal) Style Sheet
At 09:54 +0200 UTC, on 2007-04-02, Anne van Kesteren wrote: On Mon, 02 Apr 2007 09:59:50 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: [...] Surely we're not trying to ensure that a Web page is presented the same in every browsing environment? What would be the use of that? That's what people expect from us (browser vendors). Which people? And just because they expect it from you, does that mean you (browser vendors), let alone 'all of us', should give them that? So yes, that's what we're trying to ensure. Leaving aside for a moment whether it would be a good idea at all, I don't see how UA authors *can* ensure this. For example, I don't see how a site can look the same on a 21 desktop system, and a 3 portable one *and still be usable*. Add to that the possibility of a User Style Sheet, which means authors *cannot* be ensured that something will be presented this way or that. If in spite of that reality the spec say that x must be presented y, then we'd be telling Web authors they can rely on something they in reality cannot rely on. In practice, this can only result in yet more sites that are only usable to users willing to hand control over to the site's author -- even more sites that require a windows size of x, font-size of y, etc. The more specific the HTML spec says how x must be presented, the more trouble users will have configuring their UA to present content the way that is comfortable to *them*. Is HTML5 to accomodate authors, or users? [...] Not all authors will use a 'CSS zapper' (whatever it is). If that's a question, I linked to what it is in my first message in this thread: http://webrepair.org/02strategy/02certification/01requirements.php#req26 They will still expect the same results across user agents. Why should HTML5 fulfill unreasonable expectations from Web authors? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 16:20 +0200 UTC, on 2007-04-02, Thomas Broyer wrote: 2007/4/2, Asbjørn Ulsberg: [...] Should the HTML or CSS specification then encourage HTML and CSS authors to use such a zapper to get expected visual results across browsers? Why not, but such a zapper should then be given in the spec(s). Agreed. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 12:52 +0200 UTC, on 2007-04-02, Asbjørn Ulsberg wrote: On Mon, 02 Apr 2007 09:59:50 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: [display: block and inline] Defining preseantation up to *that* level is no problem IMO. Great! Then let's. The current (HTML 4) spec already does so, and in fact this is no more than a translation of HTML's distinction between block and inline level elements to CSS terminology. That translation already leads to a plethora of different results, CSS-wise. Is the whitespace around a p margin or padding? What is the default style of li elements? Do they have outside or inside alignment? Padding or margin or both? What is their line-height? I can't follow your logic. Those different results do not stem from a translation of block and inline level elements to CSS terminology [...] I didn't get the impression from the OP though that the aim was to restrict specifying of presentational defaults to this level. That's up to us to dicsuss. What level of presentation default we choose to specify is not yet specified. ;-) Maybe it would be good then if you'd start by suggesting some specific default styles. That would help us understand exactly what we're talking about. FWIW, my current view is that HTML should not define default margins, paddings, fonts/sizes, colours, etc. Having some defaults is either way better than having none, imho. Why? (The OP said informal and within limits, but didn't define that.) I didn't define it for a reason. I thought so :) I'm inviting you to define those ;) It would help make more clear what exactly we're discussing. As I asked before: how does an author provided 'CSS zapper' not do that? Should the HTML or CSS specification then encourage HTML and CSS authors to use such a zapper to get expected visual results across browsers? That would get my vote, yes. (For CSS authors. HTML has nothing to do with presentation.) How in fact does requiring default presentations remove the need for authors to provide 'CSS zappers'? You can't require anything with informal (non-normative) language. It's just the normative part of the specification that can be required and enforced. I proposed it as informal fragments for a reason, and even if the browser vendors aren't required to implement it Even if default presentations would be shoulds, the signal to Web authors would still be you can rely on your site to look like x. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 03:18 -0400 UTC, on 2007-04-02, Mike Schinkel wrote: Sander Tekelenburg wrote: [...] What exactly, in the context of presentation, would be good about consistency *across* UAs? See Jakob's Law of Internet User Experience http://www.useit.com/alertbox/2723.html I fail to see the relevance. I don't see Nielsen argue for margins, colours or fonts/sizes to be the same in every browser. (Note that I specifically said *across* UAs.) If anything, Nielsen there argues for the same type of thing I argued for at http://www.euronet.nl/~tekelenb/WWW/LINK/. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Apple Proposal for Timed Media Elements
Sorry for breaking into your realm, I just could not resist. It seems that a recording that plays just once should have the loop-count set to 0 (or left unspecified, of course). This means that the loop-count attribute cannot be used to specify that the recording should not play at all - which hardly is what you would like to do anyway. Using the name loop-count is logical and viable under this semantic correction. Christopher Yeleighton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael A. Puls II Sent: Thursday, April 05, 2007 8:09 PM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Apple Proposal for Timed Media Elements On 4/5/07, Vladimir Vukicevic [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote: 1. 'media-loop-count' is an awkward name, especially with The default value of 1 means the item will play through once but will not loop. We went through this with APNG, and ended up renaming that member. I would suggest 'media-play-count' instead -- that way there is no ambiguity with what the number means. We considered 'media-repeat-count' instead of 'media-loop-count', but that turned out to be more confusing. We really wanted all the looping-related properties to have consistent naming, and I don't think 'play' would work in the other places mentioned. The problem is that 'media-loop-count' with a value of 1, as defined, doesn't have anything to do with looping... play-count is much more descriptive of its actual purpose, IMO, despite not containing 'loop' in the name. The others should definitely stay loop-, though. I agree. To me, a loop-count of 1 means that it will play once and then loop once. If a loop-count of 1 means that it only plays once, then it's not really a loop-count. It's a play-count. I myself like how the Windows Media 6.4 API does it. It has a PlayCount that specifies how many times to play, but 0 is a valid value that means to repeat forever. -- Michael
Re: [whatwg] Apple Proposal for Timed Media Elements
Complex properties usually have their atomic counterparts in order that a script can manipulate them conveniently. That means independence is not the only factor here. ChrisY -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of L. David Baron Sent: Thursday, April 05, 2007 8:27 PM To: [EMAIL PROTECTED] List Subject: Re: [whatwg] Apple Proposal for Timed Media Elements That said, I wonder whether it would be cleaner to put all (or a bunch) of these in a single property with a complicated value syntax rather than splitting it across a whole bunch of properties. Generally one of the main considerations in determining what should be separate properties is what should cascade separately or together (e.g., what the atomic units of what a user would want to override are). The only use case I've thought of so far for property separation here is the ability to force infinite looping, although I tend to think that would be handled even better by a UA mechanism that allows the user to force the media to restart (and go through their specified looping again). -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation
