Re: [whatwg] The issue of interoperability of the video element
timeless [EMAIL PROTECTED] wrote: Desktop client content support will determine the format most content will be published in. Interesting claim, however Apple so far has introduced AAC (high quality drm-less) and MPEG4 for large audiences (OK, YouTube MPEG4 is merely announced and not technically shipping, but in a week that changes) both targeted at mobile devices. I fail to see why that relates to what I wrote. What have you done for the web lately? Someone correct me if I'm wrong, but it is my belief that discussion here is based on strength of argument, not on past credentials. By all means counter argue if you think I'm talking rubbish, but I question the value of saying What have you done for the web lately? If you must know, my presence here is as a web author with an interest in making the web a better experience. I developed an early interest in audio and video encoding formats, imo a potentially more important issue than the browser war. The issue of audio and video encoding formats will potentially give a rights holder control over the actual content that we produce and publish. I have advocated the use of open and free to use encoding formats and transport protocols for many years. (I don't count scaring companies that are trying to contribute here) I've no idea what you are referring to. I made no negative comments about any company. What evidence do you have to show that the mobile sector ever follows suit in reasonable time? I gave my opinion, your's may differ. No-one is able to prove future developments. I'm not particularly concerned with Apple's decision not to support an open free format. As I said what players with a small market share do is IMO irrelevant in relation to what will become the de facto standard of publishing audio and video content on the web. I'm sorry, I seem to have missed an introduction, which big player are you See above. and why is it OK for you to dictate terms to anyone? My prediction is based on how IE has been a major factor with the WhatWG and non IE browser manufacturers accepting that IEs market dominance effectively requires others to adopt IEs markup parsing and strive for good convergence with IE in general. It is my opinion that what will be used on the web is largely a numbers game, market share has the ability to make advocacy reasoning pretty much pointless. No-one other than market leaders have the ability to effectively dictate anything to anyone, and I fail to see how you can read my contribution to the discussion as dictating. My advocacy for open and free to use audio and video formats may well be rendered null and void after the market leaders have made their decision, but until they do I will add my voice to the debate. Sorry, this was ambiguous, I've chosen to take it to mean that you agree people shouldn't criticise companies for being concerned with laws and the risk of lawsuits. I agree. Note that I've not done so, in this or any other thread. I believe an aim of whatwg is a viable implementable standard that reflects the realities of the web while encouraging innovation. MPEG4 is part of the web (a growing part too). I agree with what I perceive to be the WhatWG's modus operandi: aim for the best solutions that can realistically be achieved. Don't engage in ivory tower idealism, accept the boundaries that the real world imposes, including commercial realities. But I don't accept that idealistic advocacy regarding encoding format support for the video element is pointless in the situation in which we are today where the market leaders haven't yet decided what they are going to do. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: Opera have already implemented support for Ogg Theora and the video tag. (see http://video.google.com.au/videoplay?docid=5545573096553082541pr=goog-sl) Opera has published a one off interim experimental build (Windows only) with video support and native Ogg Theora and Vorbis support, see http://labs.opera.com/ But this support is experimental, it remains to be seen if it will be included in future release versions, and if so with what decoder support. So far the versions published after the aforementioned experimental interim build did not support video. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: No need to encode as a java applet - all you need to do is put the java applet on the server together with your Ogg Theora content. And - by all means - this is not supposed to be an end solution, but just a fix to bridge the gap until all Browsers support the baseline codec. I don't understand why Java is needed client side if content can be authored as video src=myvid.mpg/video, but this isn't the place to explain what I presume it is caused by my lack of understanding of Java. My main worry relates to the usability and accessibility of future audio and video web content. Content including the wrapping should be free, to consume, to serve, to manipulate and to create. That basic principle should make it possible to write, publish and distribute free clients and authoring software. Combined this is imo of great importance to keep the threshold as low as possible to what might become the most extensive resource of human knowledge and communication. Audio and video are no longer peripheral in that pool of knowledge and communication, they are essential. Support in clients with a small market share like Opera and Safari is imo unlikely to be a significant consideration for content creators when deciding which encoding format to use. MS and Mozilla with their , combined ~95% of the market will probably determine what will be used. Opera and Safari will probably have to follow suit if they can. If IE and Mozilla support a common codec, and if that codec roughly meets the quality vs bandwidth requirements of content providers then imo there's a high probability that this format will be used to create future audio and video web content. Anyone know if Microsoft and Mozilla have expressed their wishes and intentions? -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Allan Sandfeld Jensen [EMAIL PROTECTED] wrote: Thus, I suggest to change the wording to User agents must support Theora video and Vorbis audio, as well as the Ogg container format. Or a clear sign that the video tag was doomed to failure anyway. I really can't imagine Microsoft or even Apple to let a multi-billion industry go, for the sake of implementing HTML5. I've been struggling with the question what purpose the video element serves if interop isn't going to be achieved, which is the current state of affairs. Afaics as it stands the following codec support is likely: IE: Windows Media and possibly MPEG4 Apple: Quicktime and MPEG4 Opera: uncertain, but not likely to support Quicktime or Windows Media Mozilla: uncertain, but not likely to support Quicktime or Windows Media Afaics the currently most used way to serve video is through Flash. From a content provider's point of view Flash has very good client support, but the quality vs bitrate ratio isn't great. Flash is likely to improve on that latter point long before browser support for the video element will reach a level for content providers to consider using it. I understand the desire amongst browser manufacturers to support video content natively regardless of the above, but afaics native browser support will be irrelevant since content providers are unlikely to start serving content using the video element and continue using Flash. Keeping it, or changing to wording will not change the behavior of Microsoft and Apple, but will only ensure that HTML5 will never become fully supported in the major browsers. Support for the video element without a common codec may well become fully supported, but pointless. Consequently and with regret I favour removing video from the spec. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: A video element that is natively part of html and has a standard set of API functions will enable applications that are impossible today, even with embedded elements such as flash. Imagine e.g. a mash-up of video extracts from several video hosting sites where you take an offset from each and put them together in a new video without having to manually edit that content. Only if all videos are in the same format and all hosting sites provide the same API will such a mashup be possible. I for one see the video and audio elements as one of the main novelties that make html5 important. You get no argument from me against the basic value of native browser support for video and audio, although imo the example you use is an edge use case and might not work in practice (with my limited knowledge of modern video encoding techniques I'm inclined to believe that the key frame nature of video formats will make it very difficult to splice encoded videos together). What I question is the practical value of specifying something that afaics will end up being useless for web deployment (controlled intranet usage could be possible). If we put a requirement into the spec for a common baseline codec and the value of that can be demonstrated through several hosting sites - e.g. wikipedia, archive.org - and new applications will be demonstrated with the new video element - then I think there is a reason to go forward. I'm uncomfortable with having a baseline codec. Even if IE would support a baseline codec, they are likely to also include a codec with a considerably better quality vs bitrate. Given their market share I fear that could result in a considerable number of content providers choosing to use the proprietary format. This would result in a schism in the availability of web content. I feel passionately that all public web content, be it text, images, audio, video or any other form should exclusively be made available using open, rights free encoding formats and transport protocols. This would result in lower quality encoding formats given the absence of commercial incentives to develop such formats and protocols, but the benefits far outweigh this drawback imo. In any case: plugins can be written for IE and for Safari that make them support Ogg Theora and the video tag, even if neither Microsoft nor Apple will be distributing them. Imo for content providers to choose video over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash simply works. Where there's a will, there's a way. We have to do what is right, not what is politically acceptable. Frustrated as I am with the current state of affairs, I don't see any point in taking a principal stance if it will result in being ignored. -- Spartanicus
Re: [whatwg] The issue of interoperability of the video element
Silvia Pfeiffer [EMAIL PROTECTED] wrote: Imo for content providers to choose video over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash simply works. Cortado is a java applet that simply works (apart from a few bugs :) and provides Ogg Theora support to Web Browsers even now. There is no need to install third-party-software, apart from Java. For Flash video to work, you have to have the Flash plugin installed. For Cortado to work, you have to have Java installed. The install-base of Flash and Cortado is probably comparable. So, client support needs to be close to Flash can be fulfilled with a bit of effort. Personally I detest Java (resource hog, slow as wading through molasses) and don't have it installed, so forgive my potential ignorance. Why create an HTML video element with the express purpose of supporting video natively in clients if video needs to be coded as a Java applet with Java handling it? And didn't MS stop including their Java in recent OSs after they lost the court case with Sun? -- Spartanicus
Re: [whatwg] Target Attribute Values
Ian Hickson [EMAIL PROTECTED] wrote: 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. If people widely blocked _blank, then authors would start using the names anyway. So that doesn't really change anything in practice. People blocking _blank would indeed be rare, even more so author's awareness of this, but I'd put the number of authors who test for conformance as significantly higher. Those authors are imo likely to look for a conformant alternative that works. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. It would be interesting to hear the needs of these authors. Can anyone elaborate? We might well need to re-allow it in the end, I'm curious to hear why people use it. In the many discussions with authors I've had on this issue, I've not yet encountered a reason for this practice that stood up to scrutiny, but regularly the lack of rationale and pointing out the negatives doesn't stop people from opening new windows despite it having been pointed out that doing so is bad practice. The most common reasons given are: 1) I like [often off-site] links opening in a new window, others will too. 2) When moving to another site, not opening a new window would cause my site to disappear (sometimes accompanied with the argument that this would confuse people). -- Spartanicus
Re: [whatwg] Target Attribute Values
Smylers [EMAIL PROTECTED] wrote: But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. Possibly, but then what's the point of making _blank non conforming if it is not trying to be a benefit to users by discouraging its use. It has nothing to do with client interoperability, real world web browsers will continue to support _blank regardless. if somebody wanted to produce a web browser that, say, was so minimalist it didn't offer any user preferences at all, surely that's up to the browser manufacturer? Possibly, the HTML4 spec mentions a browser UI facility to select between alternate stylesheets as a should. The CSS2.1 draft lists it as a must in the UA conformance section, it is also a CSS conformance requirement to offer a UA UI facility to turn off stylesheets. Browser manufacturers can ignore such, the only effect is that they can't claim to be spec conforming. User demand for such UI features expressed to the manufacturer is one way to get such features implemented. Other web specs have seen fit to add their weight to get UI features implemented. -- Spartanicus
Re: [whatwg] Target Attribute Values
Smylers [EMAIL PROTECTED] wrote: Possibly, but then what's the point of making _blank non conforming if it is not trying to be a benefit to users by discouraging its use. There's also a difference between marking something as non-conforming (because there's a better alternative which should be used instead), and completely blocking the old way of doing it. No-one has suggested that, I suggested a user configurable option to prevent HTML code resulting in opening a new window. There is already at least one browser that offers such an option. If target=_blank is ignored users can't tell that the author intended some behaviour there. That's a good thing if (as seems to be the case) it is agreed that nothing will break by opening the link in the same window. Or perhaps a help link has target=_blank and is labelled with opens in new window -- which could be dangerous if a user believed that label, only to lose her partly completed form. Such a label classifies as an authoring error, just as a href=foothis link blows up the world/a, plus calling such dangerous is imo much too strongly put, more so because the user has deliberately enabled the config setting that prevents this. -- Spartanicus
Re: [whatwg] Target Attribute Values
Lachlan Hunt [EMAIL PROTECTED] wrote: This is regarding the valid browsing context names, used for the target attribute [1]. Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. As a user I detest new windows opening without having chosen to do that myself. But I'd question the wisdom of making _blank non conforming. 1) At least _blank allows me to filter it out before sending it to my browser. 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? It could avoid the seemingly unwin'able argument with authors who insist on doing this, and give users the final say Mozilla already offers such an opt out afaik. -- Spartanicus
Re: [whatwg] Section nesting menu and an old HTML 3 friend LH
Tim Connor [EMAIL PROTECTED] wrote: As I see, there is no way to do this (my more complex variation on your example), properly, correct? I intentionally threw in a mish-mash of ways of doing it, so there is more to work with - flattened, as you did, lh's and hn's. We are just supposed to flatten all lists? h1Car and Bicycle Brands/h1 ul lhCar/lh liNissan/li liJaguar/li /ul h2Bicycle/h2 ul lih3Road Bikes/h3/li li ul liRaleigh/li liScott/li /ul /li li ul lhMountain Bikes/lh liSpecialized/li /ul /li /ul There are errors in your example code. Leaving the issue of suitability of having list headers appear in the document outline aside for the sake of discussing sectioning nested lists, the way to do what you want would be the following: h1Car and Bicycle Brands/h1 ulCar liNissan/li liJaguar/li /ul h2Bicycle/h2 ul lih3Road Bikes/h3 ul liRaleigh/li liScott/li /ul/li lih3Mountain Bikes/h3 ul liSpecialized/li /ul/li /ul -- Spartanicus
Re: [whatwg] Section nesting menu and an old HTML 3 friend LH
Simon Pieters [EMAIL PROTECTED] wrote: I tried to find use-cases for list headers, where it is desired that they not be part of the document outline. The people discussing in the aforementioned thread could not provide any real use-cases, AFAICT. I concocted an example in this article on HTML 4 heading usage: http://codewallop.110mb.com/goodpractice/headingology.htm#pseudo The example used there can be considered artificial, I don't know if forms much of a use case. More importantly, I believe that a document outline model that sub-devides the content into sections that describe/outline the content should be developed by the content author, and then implemented by coding headings, rather than the other way around (an outline that results from (potentially presentational) heading usage). That aside, I'm not convinced that there is a problem to solve here, or that a case can be made where list headings would offer any potential benefit over using a p element (leaving aside the useless it isn't a paragraph argument). -- Spartanicus
Re: [whatwg] on codecs in a 'video' tag.
Maik Merten [EMAIL PROTECTED] wrote: Well, too bad there's no royality-free, termless licensing for a baseline of H.264. The current terms ( http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) absolutely question the suitability of H.264 for free browsers (beer and speech). The licensing costs can pile up to considerable amounts (hundred of thousands of dollars) if you ship as many browser packages as e.g. Mozilla does. That's most likely an unacceptable money bleed for a zero-revenue product. Even if it wasn't, using a commercial codec as the baseline codec may require people who wish to author content using that format to pay for the privilege. This is currently the case for mp3 [1]. Although afaik this isn't currently the case for non commercial usage, the rights holders can change that at any given moment. [1] http://www.mp3licensing.com/help/index.html#4 -- Spartanicus
Re: [whatwg] video element feedback
Ian Hickson [EMAIL PROTECTED] wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. When encountering an object element IE7 seems to block all embedding by default and it issues security warnings [1] . Afaics that virtually drives the final nail in the object coffin [2]. That makes tutorials that haven't taken this into account outdated, and since UAs are not going to drop their existing support for the element I don't see why this should be an issue with regard to deprecation. [1] IE7 Information bar displayed when it encounters an object element (embedding a PNG image): To help protect your security, Internet Explorer has restricted this webpage from running scripts or ActiveX controls that could access your computer. Click here for more options. A further Security Warning dialog is produced if a user were to consider allowing it: ! Allowing active content such as script and ActiveX controls can be useful, but active content might also harm your computer. Are you sure you want to let this file run active content? Yes / No [2] Virtually since there are some cases where by using conditional comments authors can still use the advantages of the object element whilst feeding IE an img element instead. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] object, Flash, IE7
MegaZone [EMAIL PROTECTED] wrote: When encountering an object element IE7 seems to block all embedding by default and it issues security warnings [1] . Afaics that virtually drives the final nail in the object coffin [2]. I haven't seen this myself. Admittedly, I use Firefox for all my browsing, but I do have IE7 and I use it for testing pages. Some of our sites at work have Flash, and object is used. Oops, you're right. It appears that the warnings do not happen for IE's so-called Internet zone. IE's default restrictions appear to be most strict when loading a file from the local file system, more relaxed when loading from a domain that falls under IE's Local intranet group, and most relaxed for domains in its Internet group. I was expecting the opposite and had tested by loading a file from my local file system. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element proposal
Bjoern Hoehrmann [EMAIL PROTECTED] wrote: It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) Most such applications start as console applications, that changes as soon as more mainstream interest and usage results. and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size, not to mention that going from various of the formats I had meant going from works almost everywhere to works almost nowhere. Transcoding from one lossy format that is used on the web to another results in a significant reduction in quality compared to a non lossy source to lossy end format encoding, so you shouldn't make quality vs file size judgements based on that type of transcoding. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] Clarify how to indicate document hierarchy
Spartanicus [EMAIL PROTECTED] wrote: I'd much rather see different authors writing their own best authoring guidelines using their own argumentation and have these compete for adoption amongst peers. Having said that I felt obliged to write something on the subject myself. Part 1 is about heading usage: http://codewallop.110mb.com/goodpractice/headingology.htm I wanted it to be useful for web authors today, so it is entirely based on the HTML 4 vocabulary. It should demonstrate some of HTML 4's shortcomings regarding compound documents that hopefully will be alleviated by HTML 5. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element proposal
Anne van Kesteren [EMAIL PROTECTED] wrote: Opera has some internal expiremental builds with an implementation of a video element. I've observed widespread frustration amongst authors on how to offer audio and/or video on web pages. Quite a few have started using Flash since apparently it takes some of the pain out of doing so. That seems to warrant looking at a solution that doesn't use a proprietary technology like Flash. When the src= attribute is set, the user agent must immediately begin to download the specified resource, unless the user agent cannot support videos, or its support for videos has been disabled. As soon as enough data is received the user agent should start decoding the video. This means that play() and other methods can already be used before the resource is downloaded completely. I strongly dislike audio and/or video that automatically downloads and starts playing automatically, so much so that I've disabled media player plugins altogether. Both audio and video files are often considerable in size. I don't want my web browser to start making noise unless I've explicitly chosen to play audio, this should not be the result of simply loading a web page. I'd favour a spec requirement that a UA must offer users a configuration option not to automatically download and start audio and/or video and let the user decide first. Another current common frustration amongst authors is how to get file based media files to play before they've been fully downloaded. This is currently achieved by using text based redirector files containing the url to the actual media file, but these redirector formats have only been defined for a limited number of media formats. That would suggest that a UA could by default employ progressive downloading. Issue: should we very much like the img element just ignore 404 errors and the Content-Type header? And use the file extension or content sniffing? Using file extensions doesn't seem possible given the existence of wrapper formats. I imagine that a browser that can handle JPEG, PNG and GIF can use content sniffing and depending on the outcome feed it to the right decoder. I'm having difficulty imagining how that would work with video. Wouldn't that require a UA to at least be able to open the file headers of the many video file formats out there to sniff what media format is actually inside them before it can decide where to send the data? Issue: height / width Currently an issue with supplying height and width for video content embedded with the object element is that the supplied width and height includes the chrome and UI controls of the embedded player. That creates problems for authors who often don't know the size of those elements in advance, it may depend on the player and/or player skin they use. Scaling video can be very GPU intensive, so it would be helpful if there was a way to ensure that video can play in it's native size, whilst at the same time knowing in advance what room to reserve in the flow for the media and any player chrome. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] Clarify how to indicate document hierarchy
Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: SimpleBits quiz: http://tinyurl.com/create.php You need to input something and post the result for that to work. After text fallbacks, heading elements are arguably the single most important accessibility feature HTML offers. They allow assistive technology users to jump between sections of a document, rather than being forced to listen to or read the entire stream. Imo there is considerable wishful thinking behind that thought. IIRC no current AT AU facilitates navigating for example from one h2 to the next h2, they only allow navigating to the next or previous header. That significantly reduces the potential usefulness of header navigation. But IMO the real killer is the chicken and egg situation that very few pages have been marked up to facilitate useful header navigation. Consequently as a user you'd have to be something of a masochist to try and use header navigation whilst surfing. In turn there is little incentive on UA developers to improve their header navigation feature. WHATWG's specifications should establish clear guidelines about how document hierarchy can be indicated. Should a specification also be an authoring course? IMO it is appropriate for a spec to contain single illustrations/examples of a given element usage, and such examples should IMO follow common best authoring practice if one exists, but IMO it is not appropriate to expand a spec into an authoring course. The issues you mentioned have been a pet subject of mine for some time, however I'd be amongst the first to acknowledge that the real world practical benefits of what I advocate (which seems to align with your views) could be negligible. This, combined with the fact that, as you noted, there are differing views on what constitutes best authoring practice is another argument that this is not something a specification should get involved with. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] Clarify how to indicate document hierarchy
Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Of course, just because the HTML4 spec goes in for this stuff doesn't itself mean it's a good idea. What I'd hate to see happen is that we'd end up with best authoring guidelines incorporated into the HTML 5 spec were those guidelines end up being as contentious as for example the WAI 2.0 guidelines turned out to be. And IMO the potential for such contention is significant. Incorporating verbose guidelines into the spec itself would increase the exposure, but at the expense of: * Having to compromise the spec's structure to accommodate different goals * Significantly increasing the amount of work for Ian * The aforementioned risk of contention which might cause some people to resent HTML 5 I'd much rather see different authors writing their own best authoring guidelines using their own argumentation and have these compete for adoption amongst peers. IMO some of the benefits of this are: * More dynamic and creative usage of the language * No constraints on discussing the full arsenal of techniques (for example CSS) needed to achieve the required goal My preference would be to have a page on the WhatWG site that links to such authoring guidelines accompanied with a warning that they are not necessarily endorsed by the group. The spec itself could then refer people looking for more verbose usage guidelines to that page. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] several messages about XML syntax and HTML5
Mike Schinkel [EMAIL PROTECTED] wrote: Google, Yahoo and MSN aren't in the business of enforcing a standards- compliance agenda. Who is? A better question to ask would be to whom does it matter?. Is it really relevant to give your opinion of my grammer? I didn't, who is [in the business of enforcing a standards- compliance agenda] is a different question than to whom does [standards compliance] matter. I wanted to make the point that standards compliance is in itself irrelevant to SE users/the average web user. SE's have nothing to gain from markup validity. Of course they do. Better markup makes the results of their web page analysis more accurate, especially when semantic markup is involved. That can lead to better search engine results. I'm not seeing much evidence of that. Afaics SEs are interested in text content, links, title content and if you're lucky they may treat header content slightly differently. They seem to treat the most of the other angled bracket stuff as noise, and justifiably so. Proper semantics and correctly structured content could be of benefit, but that is a very different, and much higher goal than mere compliance with the technical rules of a markup language. Markup validity is irrelevant to SEs, not only do they currently not care about it, they likely never will, since there's nothing to be gained from it. They should serve up results relevant to their users, Again, you state should as if you are quoting from an authority. In a free market, I'm not aware of such an authority except in limited cases where I don't see that this applies. So should is just your narrow viewed opinion which is no more correct than my broader viewed opinion. should (in lower case) should not g be read as per RFC 2119, that should be (I'm a bad boy) reserved to the upper case usage of the word. I'm going back to lurk mode, as I've strayed well beyond the purpose of this list (sorry). -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] several messages about XML syntax and HTML5
Mike Schinkel [EMAIL PROTECTED] wrote: Google, Yahoo and MSN aren't in the business of enforcing a standards- compliance agenda. Who is? A better question to ask would be to whom does it matter?. SE's have nothing to gain from markup validity. They should serve up results relevant to their users, their users use tag soup parsers with error correcting mechanisms. What might be a slight bonus to them: a properly defined error handling mechanism that is very closely matched to what browsers do, ergo what the WhatWG parsing spec aims for. And at the risk of sounding snarky, can you point me to a reference where is it codified that they are not (at least partially) in the business of standards? http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com http://validator.w3.org/check?uri=http%3A%2F%2Fwww.yahoo.com http://validator.w3.org/check?uri=http%3A%2F%2Fwww.tech.msn.com Should give some indication. (I had to cheat slightly with MSN, the sneaky boys made the home page on msn.com validate to throw people off, but as I suspected the document at the first link from msn.com I tried failed validation :-) -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] HTML syntax: comments before doctype and doctype sniffing
Simon Pieters [EMAIL PROTECTED] wrote: The parsing section says that a comment before the doctype may trigger quirks mode. I'm assuming that this comment merely documents IE's current behaviour. Please ignore my other comment if I'm wrong. Therefore I think the syntax section shouldn't allow comments before the doctype (only space characters). There are valid reasons to kick IE into quirks mode whilst triggering standards mode in other browsers. There is existing content on the web that intentionally does this. Why would you want to deny an author who fully understands the issues from doing this? -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] img element comments
Ian Hickson [EMAIL PROTECTED] wrote: [width and height attribute on the img element] I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? Definitely on the integer value only, allowing percentage values makes no sense to me. In some cases I have used just one attribute http://homepage.ntlworld.ie/spartanicus/fit_image_in_column2.htm , but on examination this does not only have no benefit, it needlessly causes the single coded image size to be reserved in the flow if for example a graphical client is configured to not initially retrieve images. When omitting both attributes the element's size collapses to the size of the alt content, whilst the reflow on a possible subsequent retrieval of the image occurs anyway in this particular scenario. Meanwhile allowing authors to omit width height together caters for situations where better functionality is achieved if the natural dimension of the image isn't reserved on the initial flow layout. The required reflow on a subsequent retrieval of the image can be considered preferable compared to the alternative where potentially valuable screen space may be wasted to reserve space in the initial flow for the natural size of the image. So I also support requiring both to be present if either is present. But wouldn't requiring the width height values to be equal to the natural dimension of the image require conformance checkers to have a capability to parse images to retrieve these values? -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] img element comments
On Fri, 03 Nov 2006 19:38:37 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: * Regarding the alt attribute, wouldn't it make sense to just allow it to be omitted? In terms of meaning it seems the same. I have always considered requiring the alt attribute resulting in the use of alt= as an anomaly. On the other hand, it probably shows the difference between people who thought of the alternative representation and people that haven't. Many authoring tools generate alt= by default, mine does. It is then up to the coder to do the right thing, but the tool will frequently not prompt him to do so. For that reason I don't think that the presence of alt= can reasonably be considered as having been a conscious decision. I'm note sure if a UA treating the absence of an alt attribute differently from alt= would benefit a user. Alexey Feldgendler [EMAIL PROTECTED] wrote: The problem with allowing omission of alt depends on the meaning of img without alt. If img without alt is defined to mean the same as img with alt=, then the problem is that all cases when people omit the alt attribute because they don't care will end up with mangled meaning. I don't see that as changing anything. Documents containing content images without alt content are broken regarding this aspect, and they will remain so if img without an alt attribute is considered equal to img elements with alt=. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
