Re: [whatwg] The truth about Nokias claims
Shannon, I meant that the removal of the paragraph from the spec (which was done *after* Nokia sent its paper) does not hold any consequences. The final content of the video specification of course does. Apologies if this was unclear. The volume of traffic may be proportional, but most of its content is repeating the same arguments over and over again. I don't think this is of any use for the debate and a more pragmatic viewpoint might be of use for some of us. This is an argument for AND against changing the text. Therefore not an argument at all. I would say that the fact h.264 fees become due in 2010 would be a case for discussing this now. I didn't say video should not be discussed right now, on the contrary, like all issues it certainly should. My problem is mainly that a lot of contributors to the mailing list are making this debate too heated for its own good. There is time to come to a reasonable solution, and it will not be an easy one, as Ian said. Simply bashing Apple/Nokia/Ian does not help here. It is not simply a matter of reverting the spec to say Theora is the recommended format (as you seemed to be asking for a few replies ago), as it has been stated several times before that there are major browser vendors that will not implement this, and HTML5 naturally seeks to be a specification that will be implemented by as many as possible. Even though a SHOULD is not technically required for conformance, including a SHOULD that we know beforehand won't be implemented is of no use. Regards, Stijn ---Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Shannon Verzonden: vrijdag 14 december 2007 9:07 Aan: whatwg@lists.whatwg.org Onderwerp: Re: [whatwg] The truth about Nokias claims Stijn Peeters wrote: It does not hold any consequences for the final spec. Of course it does, or Nokia would not have taken issue with it. When this comes up in the future somebody will claim 'we've been over that' when the issue could have been resolved now. Putting this on hold changes nothing except to stifle debate. What's worse is that all the arguments made now will have to be repeated. I do not understand why someone would be holding HTML5 ransom over this. Because they have patents and existing investment in other formats. Are they denying that? No. Are they obsfucating that? Yes. HTML5 is more than video. According to the road map the final HTML5 recommendation is due in late 2010. This is an argument for AND against changing the text. Therefore not an argument at all. I would say that the fact h.264 fees become due in 2010 would be a case for discussing this now. There is still plenty of time to discuss the issue and come to a reasonable solution, and while you might find video more important than cite, cite is also something to be discussed. I didn't say it wasn't. What I said was the volume of traffic on the video element is proportional to its importance and therefore not a reason to shut down the debate. Shannon
Re: [whatwg] The truth about Nokias claims
Shannon, What concerns me is that the removed OGG recommendation (specified as SHOULD rather than MUST) was a step forward to the adoption (however reluctantly) by corporations and governments of a set of formats that require no royalties to encode, decode, reverse-engineer or distribute. None of the status quo formats can make that claim. Several people on this list have claimed that recommending OGG would have legal implications for vendors. It does not. Those who feel threatened have the option to not implement it - without affecting compliance. In nearly all cases the end-user would have been subject to the minor inconvenience of finding an alternate source of OGG support. What concerns me most is that the people making contrary claims know this yet argue anyway. Their motives and affilations, to me, are suspect. [...] Supporting OGG now in no way prevents a better option (such as Matroska and/or Dirac) being added in the future. Nor does it prevent SHOULD being changed to MUST. As I said, a SHOULD requirement in the specification which will (given the current status quo) not be followed by the major(ity of) browser vendors is useless and should be improved so it is a recommendation which at least can be implemented. Changing the SHOULD to MUST means that a lot of browser vendors would not be able to develop a conforming implementation. Governments do generally not build browsers or HTML parsers so an HTML specification would likely not influence them much, and I believe they are not who such a specification is aimed at. Some claim that recommending no baseline format is neutral ground. The amount of outrage this triggered proves that is false. The claim that we have not reached a decision is true (my opponents use this claim to support their 'neutrality'). Yet it is clear to me that NOT setting a standard is as influential in this case as setting one. Indecision with no reasonable grounds for ending it leads to the status quo as I have said. Is it not the purpose (and within the powers of) of a standards body to steer the status quo? Is it not in the public interest that this happens? Indeed it is, which is why this issue is being discussed on this list right now. HTML4 advocated GIF, JPG and PNG even if the wording made it seem optional. The result was full support for 2 of these formats and partial support of the third. There is no reason to believe that putting a SHOULD recommendation in the text wouldn't result in most browsers supporting OGG (except IE). This in turn would give public, non-profit and non-aligned (with MPEG-LA) organizations justification to release materials in this format rather than Flash, WMV or MOV (all of which require commercial plugins and restrictive licenses). As stated before, it did not advocate them, merely stated them as *examples* of image formats. Your claim that HTML4 played a substantial role in adoption of GIF and JPEG is interesting. Do you have any sources for that? HTML4 states Examples of widely recognized image formats include GIF, JPEG, and PNG.[1], implying those formats were already widely adopted before it was published. This is different from what HTML5 is going to do, which is recommending a specific format that implementations *should* support. Regards, Stijn [1] http://www.w3.org/TR/REC-html40-971218/struct/objects.html#h-13.2 Some claim pro-OGG supporters started this debate. It was Nokia who made this a headline issue. Objectors claim they are working towards a resolution that defines a MUST video format and is accepted by 'all parties'. I don't believe that because they know this is impossible and it WILL affect HTML5 adoption. There is no format that can satisfy their unreasonable expectations. There never will be. We live in a world where companies claim patents on 'double-clicking' and 'moving pictures on a screen'. How then can any format ever meet their demands? I hope I have made my position clear. I hope my position represents the public interest. I am not here just to nag (I have been on this list for over two years and have only intervened once before). I am writing in the hope that proper discussion takes place and that future decisions of this magnitude are not made without public consultation - in the interests of entrenched cabals. I would like to say I believe all those opposing OGG have our best interests at heart - but that would be a lie. I am too old to believe companies and their spokespeople are altruistic (sorry Dave). Shannon
Re: [whatwg] The truth about Nokias claims
Quoting Ian, [as a codec that everyone will implement] Theora is not an option, since we have clear statements from multiple vendors that they will not implement Theora.. So, in your wording, multiple vendors will choose not to develop one. Writing a spec while knowing beforehand that multiple vendors will not implement it conformingly still sounds like a bad idea to me :) Regards, Stijn -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Jeff McAdams Verzonden: vrijdag 14 december 2007 14:13 CC: whatwg@lists.whatwg.org Onderwerp: Re: [whatwg] The truth about Nokias claims Stijn Peeters wrote: Changing the SHOULD to MUST means that a lot of browser vendors would not be able to develop a conforming implementation. Again, this needs to be called out as being patently untrue. They might *choose* not to develop a conforming implemention, but they certainly are *able* to. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: [whatwg] The truth about Nokias claims
Shannon, You seem to have missed Dave's point. The removal of the paragraph mentioning OGG in the spec does not change anything. The spec is a work-in-progress and the video tag is still under discussion. As such, the spec has been changed to reflect that no decision regarding this has been made yet. This does not change anything as that part of the spec was work-in-progress anyway. Why would he discuss such an editorial change with the list first? It does not hold any consequences for the final spec. I do not understand why someone would be holding HTML5 ransom over this. HTML5 is more than video. According to the road map the final HTML5 recommendation is due in late 2010. There is still plenty of time to discuss the issue and come to a reasonable solution, and while you might find video more important than cite, cite is also something to be discussed. Regards, Stijn -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Shannon Verzonden: vrijdag 14 december 2007 8:16 Aan: whatwg@lists.whatwg.org Onderwerp: Re: [whatwg] The truth about Nokias claims Ian, as editor, was asked to do this. It was a reasonable request to reflect work in progress. He did not take unilateral action. Ok, not unilateral. How about 'behind closed doors?'. Why no open discussion BEFORE the change? 4.) What prevents a third party plugin open-source from providing Ogg support on Safari and Nokia browsers? Nothing, but if the spec. required the support, the browser makers cannot claim conformance. The spec did not REQUIRE the support, it recommended it. You've now confirmed that doesn't cause non-compliance. 5.) Why are we waiting for ALL parties to agree when we all know they won't? Why can't the majority have their way in the absence of 100% agreement? Because we have the time to try to find a solution everyone can get behind. It's not as if we are holding final approval of HTML5 on this issue. There is plenty of technical work to do (even on the video and audio tags) while we try to find the best solution. Actually it appears that somebody was holding HTML5 to ransom on this issue. Now you've caved in. Now the rest of us are holding it. Touche? Anyway, this is a great idea except 100% agreement is practically impossible. Are you claiming otherwise? We don't need a vote. That just about says it all, doesn't it? Is this a public standard or not? What is this list? 6.) How much compelling content is required before the draft is reverted. Does Wikipeadia count as compelling? When will I stop beating my wife? Your question has a false assumption in it, that we are waiting for compelling content in order to revert the draft. We're not. We're working on understanding. Then what ARE you waiting on (what PRACTICAL thing I mean)? Understanding what? My understanding is perfect. The MPEG-LA is upset with the Ogg proposal. Also, when will you stop beating your wife? (since you brought it up). Ian has claimed compelling content could end this impasse. I do not believe it (any more than I believe you beat your wife). As Ian has said, we are going in circles on this list, with much heat and very little if any new light. Can we stop? It is getting quite tedious to hear see the same strawmen bashed on again and again. Of course people would like this to end. Some more than others. It would help if those involved in creating the controversial changes would come up with a practical solution but they can't. If would help even more if you agreed to restore the text. And who is blocking the light? Who created the strawmen? Was it Nokia claiming that Ogg was 'proprietary' (conveniently ignoring the fact it is public-domain). You claim 100% agreement is necessary to revoke the change. If so why wasn't it necessary BEFORE the change? The way I see it we are expected to wait for an impossible event. No new protocol can possibly pass the expired patents test for at least 10 years. Are you planning to wait that long to ratify HTML5? I am NOT the villain here. MY interest in this matter is altruistic (as a web developer and user). I do not work for a company with existing commitments to a particular format. If I keep the debate going then it's because the answers given are unsatisfactory. I apologise to the rest of the list but this is an much more serious issue than the format of the cite tag to me. Shannon
Re: [whatwg] lede element
Rachid Finge schreef: The term 'lede' is more commonly spelled as 'lead' by journalists throughout the world. It seems like a sensible idea, although I'm wondering why you added the P element in your example. I'm not an expert on this, but wikipedia distinguishes them (of course wikipedia is not absolute truth): Lede (pronounced /lid/) is a traditional spelling, from the archaic English, used to avoid confusion with the printing press type formerly made from lead or the typographical term 'leading'. [1] Anyway, I think this is a sensible idea indeed. I suppose the lede element would be used inside a p element, surrounding the first sentence or so, as a lead/lede is different from (or, as far as I know, a part of) the first paragraph. Regards, Stijn [1] http://en.wikipedia.org/wiki/Lede_%28news%29#Terms_and_structure
Re: [Whatwg] Request for HTML-only print link
Sander schreef: Křištof Želechovski schreef: The acronym URL expands to Uniform Resource **Locator**”. The string “print:#” does not match this spec: it is not a locator, it is a processing instruction. BTW, the full form of the local URL “#” can be viewed as “html:#” (whether it is allowed by the URL standard or not) which means that you need a URL to access the resource you want to print; prefixing it with “print:” would result in a double URL scheme, which is unacceptable. Therefore it is better to use a special target, if any. Would href=print://www.whatwg.org/specs/web-apps/current-work/ have been better then? I think new URI schemes are outside the scope of the WHATWG work. See also http://rfc.net/std0066.html#s3.1. and http://rfc.net/rfc2718.html Regards, Stijn
Re: [Whatwg] Request for HTML-only print link
Sander schreef: Stijn Peeters schreef: Sander schreef: Křištof Želechovski schreef: The acronym URL expands to Uniform Resource **Locator**”. The string “print:#” does not match this spec: it is not a locator, it is a processing instruction. BTW, the full form of the local URL “#” can be viewed as “html:#” (whether it is allowed by the URL standard or not) which means that you need a URL to access the resource you want to print; prefixing it with “print:” would result in a double URL scheme, which is unacceptable. Therefore it is better to use a special target, if any. Would href=print://www.whatwg.org/specs/web-apps/current-work/ have been better then? I think new URI schemes are outside the scope of the WHATWG work. See also http://rfc.net/std0066.html#s3.1. and http://rfc.net/rfc2718.html My initial request was not about a specific technique, but about a functionality. If a pseudo-protocol is not an option, maybe there's another solution. cheers, Sander Certainly, just wanted to point out that in the case you'd consider a URI scheme the best option, this was not the appropriate place to discuss it further. As for the request itself, I think I agree with Lachlan: I do not see a real reason to implement something that is already perfectly covered by javascript:print(). It is indeed basic funtionality of most browsers but I think this is also a reason _not_ to implement a specific attribute or element for this, as it would be redundant. Javascript has traditionally been used as a means of accessing the browser's functionality (back, forward, refresh, input prompts, confirmation dialogs...) and printing fits well in there. Regards, Stijn
Re: [Whatwg] Request for HTML-only print link
Křištof Želechovski schreef: href=print://www.whatwg.org/specs/web-apps/current-work/ is no good; it asks the browser to find the resource using the print protocol. But the print protocol is for printing, not for finding resources; I imagine it could be used for finding out some printer configuration parameters (similar to the way printers with a network interface only can be configured) and to submit documents for printing, nothing more. How about form action=print://host_name/printer_name/? href=quo;http://www.whatwg.org/specs/web-apps/current-work/quo;amp; palette=monoamp; copies=3amp; mode=draft,bookletamp; stapled=top method=post input type=submit value=Print me/form ? It feels better to me. Of course, the arguments would be interpreted by the browser, not by the printer, contrary to what the syntax suggests, but I think this problem is much smaller and I can swallow it in spite of being a purist. The idea that a fragment can address a block element is quite interesting; in the old days a reference to #name would usually correspond to an anchor with the same name—and you cannot embrace a block-level element with an anchor. I think it is still common practice to put the named anchor around the section header and not around the whole section, which would require a division, not an anchor. I did not want to say that printing is obsolete; I wanted to say that asking the customer to print is obsolete. Sorry for the misunderstanding. Your site should not lose functionality because your customer does not have a printer. Cheers Chris A link of the format print://host_name/printer_name would never be feasible because on the server side it can not be properly guessed what the name of the printer and the server it is on (if any) on the client side would be. A theoretical solution would be somehow finding the printer's location via Javascript (though this is fundamentally impossible, as far as I know), in which case you could as well use javascript:print(). Besides, no such protocol exists, and defining it is as I pointed out earlier not in the scope of the specs the WHATWG is working on. Regards, Stijn
Re: [Whatwg] Request for HTML-only print link
Sander schreef: Sander Tekelenburg schreef: Your main argument for a print links seemed to be that some people might not know where to find their UA's print command (hard to believe -- even IE by default presents a shiny print button always). Well, Opera doesn't show a print button for instance. It does however have a File - Print option, which is the place where this option is in virtually all programs offering printing functionality, and therefore most probably the first place someone will look. Regards, Stijn
Re: [Whatwg] Request for HTML-only print link
Sander schreef: Sander Tekelenburg schreef: A lot of site owners just don't want to do that as it turns the focus on the browser instead of their. Well, tough :) Users matter more than authors. (See http://esw.w3.org/topic/HTML/ProposedDesignPrinciples#head-97abe59da6732ca0ab8a6d9d863b100bf1e51266.) So when what authors want to do harms users, it is not a good idea to have HTML cater for those authors. But a lot of users just don't know their browser and they just don't really bother to learn. They want things the easiest way, which in this case would be that print does print when you click on it. I agree that it would be best if users knew how to use their applications to the full extend, but that's just not reality for a large part of users. Perhaps you have geek parents. I don't and I know a lot of people like them who don't even know what a browser is although they use them every now and then or even quite regularly. They don't have to know it is a browser. All major browsers follow certain interface conventions, one of them being that the print dialog is located under File. The average computer user you are talking about, with little knowledge about browsers and the like, will probably assume that this program (the browser) also follows the convention and look for the print option where they expect it to be - File, the place where it also is in their e-mail program, word processor, MS Paint, whatever. If the browser does not follow these conventions, then the average computer user is probably not using it. That a control is, in certain browsers, hidden in a menu somewhere is not a valid reason to make it directly accessible from HTML. The browser's user interface however is not relevant at all here. For all you know your site is being viewed via a chromeless window - how is the user going to navigate forwards and backwards then? There are no buttons for those actions either. Just because not all user agents have the same functionality or interface features does not mean that HTML should make up for that. On the contrary - somehow enabling HTML to control printing would imply that a conforming UA is expected to support this, while it should be completely irrelevant whether the UA supports printing or not. Anyway, as Anne pointed out earlier, the functionality you originally requested is already somewhat implemented. a media=print would indicate to the UA that the document pointed to was meant for printing; this should be enough already. I can imagine an UA handling a link for media=print would somehow indicate this to the user. I would agree that this could perhaps be defined more clearly in the spec. However having an attribute or technique specifically designed for printing out something is in my opinion, for the reasons I stated above and those which were mentioned by others, outside the scope of HTML and undesirable. Regards, Stijn
[whatwg] [WF2] Clear On Focus attribute
It is becoming increasingly common to have an input field clear its value when it is first focused. Though in a lot of cases this is actually wrong usage of the value= attribute for something which should actually be done with label (such as a search box filled with Enter search query here that becomes empty when you first click it), it is possible to come up with legitimate use cases; the first thing that comes to mind are input fields with placeholder or default values that may need to be changed. This goes well together with WF2's new abilities for prefilling forms. It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. Currently this is mostly done through javascript, which is not necessarily a bad thing, but seeing that attributes such as autofocus= have also found their way into the spec, I suppose this is also inside the scope of Web Forms 2 or HTML5. As for the attribute name, clearonfocus= with clearonfocus as the only possible value (indicating the input field or textarea should be cleared upon focusing it) would probably be most suitable. -- Regards, Stijn Peeters
