Re: [whatwg] The issue of interoperability of the element
"Silvia Pfeiffer" <[EMAIL PROTECTED]> wrote: >Opera have already implemented support for Ogg Theora and the tag. >(see http://video.google.com.au/videoplay?docid=5545573096553082541&pr=goog-sl) Opera has published a one off interim experimental build (Windows only) with 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 . -- Spartanicus
Re: [whatwg] The issue of interoperability of the 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 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 element
timeless <[EMAIL PROTECTED]> wrote: >> My main worry relates to the usability and accessibility of future audio >> and video web content. Content including the wrapping should be free, > >you don't quite mean that. if a content producer wants to make pay >content, it should be free to do that too, no? There are huge >industries which drive a large portion of the industrialized world >based on a premise like this. I am referring to public web content. Subscription services, pay per view or similar schemes are a different story. Consider that the formats currently used to publish for example public web text and images are open and free, this hasn't been an obstacle to commercially exploit writing or image authoring. Obviously there is an issue with copyright enforcement, but that is unrelated to proprietary content formats. >Unless they're targetting the mobile market which is basically >dominated by Opera and WebKit (Safari and a Nokia derivative). I am not familiar with the code base used by WebKit for mobile devices, but afaik Opera for mobile devices uses the same rendering engine and has the same content format support as their desktop software. >> MS and Mozilla with their , >> combined ~95% of the market will probably determine what will be used. > >Again, this is dependent on the market. In Korea, the market says you >must use IE because of the crypto layer. In the mobile market, the >considerations are different. Desktop client content support will determine the format most content will be published in. Making a different choice for the mobile segment is not only very costly, it will deny mobile access to the majority of web audio and video content. IMO the mobile sector will follow suit unless there are insurmountable problems using the same format there. >I can't speak for Nokia any more than >Dave or any of the other Apple employees can speak for Apple, but >shipping ogg is currently not an option. 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. >We tabled the ogg discussion >a while ago, this advocacy is a huge waste of electronic bits. Agreed with regard to the criticism of Apple. Couldn't disagree more with regard to fighting for open and free web content formats. -- Spartanicus
Re: [whatwg] The issue of interoperability of the 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 , 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 element
"Silvia Pfeiffer" <[EMAIL PROTECTED]> wrote: >> Imo for content providers to choose 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 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] The issue of interoperability of the element
"Silvia Pfeiffer" <[EMAIL PROTECTED]> wrote: >A 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 and 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 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 tag, even if neither Microsoft >nor Apple will be distributing them. Imo for content providers to choose 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 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 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 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 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 element without a common codec may well become fully supported, but pointless. Consequently and with regret I favour removing from the spec. -- 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 this link blows up the world, 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
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
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
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? > >Car and Bicycle Brands > > Car > Nissan > Jaguar > >Bicycle > > Road Bikes > > > Raleigh > Scott > > > > > Mountain Bikes > Specialized > > > 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: Car and Bicycle Brands Car Nissan Jaguar Bicycle Road Bikes Raleigh Scott Mountain Bikes Specialized -- 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 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] , 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 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 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] element feedback
Sander Tekelenburg <[EMAIL PROTECTED]> wrote: >IMO this is no different than CSS being icing on the cake. It's nice to allow >authors to suggest UI-styling and even add functionaility, but it's a mistake >to make basic functinality (start, stop, pause, (fast)forward, etc.) >author-dependant. Recently I have begun to fear that the principle of not relying on CSS [1] and/or Javascript for anything essential has also been abandoned by various specifications. But if I'm wrong and this fight hasn't yet been lost, I'd like to add my voice to not relying on JS for anything essential at least from a specification angle. [1] CSS3 generated content WD enables blurring the distinction between content and styling by enabling fall back content: http://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting3 Example: content: url(danger.png), "Danger!" -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] element feedback
Ian Hickson <[EMAIL PROTECTED]> wrote: >> However, I think if 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 . 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 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 element instead. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] 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] element proposal
"Anne van Kesteren" <[EMAIL PROTECTED]> wrote: >Opera has some internal expiremental builds with an implementation of a > 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 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: >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] Clarify how to indicate document hierarchy
Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> wrote: >> IIRC no current AT AU facilitates navigating for example from one to the >> next , they only allow navigating to the next or previous header. > >Even being able to skip from heading to heading is vast improvement, but >I'm delighted to say you're wrong about current AT capabilities. This >isn't a full survey but: > >JAWS does: [...] Thanks for the research, this is good news. >> But IMO the real killer is the chicken and egg situation >> that very few pages have been marked up to facilitate useful header >> navigation. > >Seems to me a lot of pages uses header navigation. Headers being used in web documents does not mean that they form a useful navigation mechanism. >(Hixie will presumably have some statistics on this.) The usefulness cannot be derived from the data produced by a markup parsing bot. >> Should a specification also be an authoring course? > >You mean should a specification indicate best practice or only required >practice? IMO a spec should primarily describe the building blocks, i.e. the available elements and if needed illustrate their usage with minimal context. How to use those elements to build a page or site is up to authors. It depends on variables such UA features and support, UA market share, user behaviour, fashions, fads and other slippery modalities. This IMO is not something a spec should get involved with. >It should indicate both IMHO, and in many places both the >HTML4 specification and the WHATWG drafts do just that. I see no guidance of the type you requested in the HTML4 spec. Whilst I can understand your desire for this type of advocacy, a language specification is IMO not a good place for such. -- 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 to the next , 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] contenteditable, and
"Alexey Feldgendler" <[EMAIL PROTECTED]> wrote: >> It often is, sadly. When people really, really want a grid layout model >> and try to fake it with positioning or floats, the result tends to be >> more brittle and (particularly with positioning) less fluidly scalable >> than a layout (positioning being worse than floats but see >> http://dbaron.org/log/2005-12#e20051228a ). > >Just a side note: for grid layouts, display: table-* should be used. CSS table layouts share all of the many drawbacks of HTML table layouts, except for the false semantics (one of the least significant issues IMO). Afaics this is off topic for this list, so I'm not going to add further to this thread spin off. -- 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 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 doctypesniffing
"Simon Pieters" <[EMAIL PROTECTED]> wrote: >>I'm assuming that this comment merely documents IE's current behaviour. >>Please ignore my other comment if I'm wrong. > >A comment before the doctype has equal status as lack of doctype or an >incorrect doctype. Hence, conformance checkers will flag such documents as >non-conforming, and the syntax section should only allow things that will >pass conformance checking. OK, I noticed that myself whilst experimenting with Henri's validator recently. If the current HTML5 draft is contradictory in the parsing vs syntax section then that could make arguments to allow it irrelevant. >>There are valid reasons to kick IE into quirks mode whilst triggering >>"standards mode" in other browsers. > >What are those reasons? I could be way off base here, but I expected future HTML5 compliant browsers not to change the doctype sniffing mechanisms/rules that are currently used, since as far as I understand the HTML5 currently already triggers standards mode in current browsers. If that assumption is true then allowing SGML comments to precede the doctype could result in better compatibility of such future HTML5 compliant browsers with existing web content authored to trigger quirks mode in IE. Some examples of why triggering IE's quirks mode could be useful to authors: IE6 in "standards mode" introduces new bugs compared to IE5.5. Since IE6 in quirks mode does a pretty good job of emulating the 5.5 bugs, an author may prefer to deal with one set of IE bugs and associated workarounds and hacks. I have authored sites with the aim of keeping them compatible with IE5.5 without resorting to IE5.5 vs IE6 distinguishing hacks such as the Tantek hack. Kicking IE6 into quirks mode was the easier option. I orphaned off a number of sites some time ago, this was before the IE7 betas emerged. In the hope of standing a better chance of getting those sites to render in a future IE7 I gambled that MS might restrict for example support for the child selector to "standards mode". These sites extensively used the child selector hack to apply fallback CSS for IE and advanced CSS for proper browsers, advanced CSS that by that time I knew IE7 was unlikely to support (like generated content or CSS tables). -- 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] 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 >without alt. If without alt is defined to mean the same as 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 without an alt attribute is considered equal to elements with alt="". -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] element comments
Matthew Raymond <[EMAIL PROTECTED]> wrote: >Michel Fortin wrote: >> Except that, contrary to bgcolor, the height and width attributes can >> help solve a real problem: page jiggling while the images loads. It's >> somewhat like the type="image/jpg" attribute you can set for links: >> it gives advance information on what the external content is supposed >> to be. > > So does CSS, as you point out below. Indeed, but then there is the mantra that CSS should be considered 100% optional since the CSS may not be used for various reasons like network trouble. Afaics the question then seems to be; is preventing reflows a serious enough issue to not delegate it to CSS? > The |width| and |height| attributes don't specify the dimensions of >the source image. They specify the size of the image in the document. >That's presentational, in my book. Arguing that those attributes are >properties of the image within the document amounts to a free pass for >all presentational markup. The , , and elements >communicate a property of the text, not the presentation. I don't buy >it. Without the attributes actually describing a property of the source >image (which is redundant), the |height| and |width| have no semantic >meaning. Convenient as they are, they're styling as markup. I don't believe that using a strict presentational vs semantic model is helpful or even possible, nor do I believe that allowing width & height attributes could create a precedent. The question should be if maintaining these serves a valid useful purpose. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] element comments
Ian Hickson <[EMAIL PROTECTED]> wrote: [width and height attribute on the 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)
