Re: [whatwg] usemap= and related issues
On Fri, Nov 28, 2008 at 3:00 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Jonas Sicking wrote: Ian Hickson wrote: On Thu, 26 Jun 2008, Jonas Sicking wrote: What I did notice in our code though is how we deal with the case when there are multiple maps with the same name. In this case we generally use the first map. But if the first map is empty, we use the first non-empty map. This was done for compatibility with some sites. See https://bugzilla.mozilla.org/show_bug.cgi?id=264624 I have no idea if this matters today or not. I couldn't reproduce this behavior. Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks mode things spread into code that I work on ;) ). If no other browser is doing it in standards mode either I'm more than happy to not have it in the spec. / Jonas
Re: [whatwg] video tag: pixel aspect ratio
On Sun, Nov 30, 2008 at 11:05 PM, Chris Double [EMAIL PROTECTED] wrote: On Mon, Dec 1, 2008 at 7:11 PM, Peter Kasting [EMAIL PROTECTED] wrote: I don't think it is the end of the world if this attribute goes in, but I see very little benefit to it, and I am always for removing items with marginal utility. I'm inclined to agree. I think it's odd that an attribute is being added to fix video's encoded incorrectly. Why can't the author of the video fix the actual video? One of the arguments for captions being embedded in video's rather than having some way of defining captions by the page author was that it's important not to use HTML to fix broken videos, and allow captions to travel with the file. The same argument could be made for pixel ratio. Fixing it in the HTML means everyone linking to the file using video will need to remember to add pixelratio to their HTML. Better to fix the file. Can someone provide examples of videos on the web that are currently broken, and a pixel ratio that would fix it? As an HTML author that wants to embed a video on my website I don't think I'd have any idea how to come up with a pixel ratio to fix it. Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) / Jonas
Re: [whatwg] Question regarding accessibility for img
From: Benjamin Hawkes-Lewis [EMAIL PROTECTED] To: Geoffrey Sneddon [EMAIL PROTECTED] Cc: Pentasis [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Sunday, November 30, 2008 9:56 PM Subject: Re: [whatwg] Question regarding accessibility for img Geoffrey Sneddon wrote: On 30 Nov 2008, at 16:40, Pentasis wrote: I notice that it says in the spec under the img-section: There has been some suggestion that the longdesc attribute from HTML4, or some other mechanism that is more powerful than alt=, should be included. This has not yet been considered. May I ask why it has not been considered (yet)? Because there's an issues list of several thousand issues, and as such not all issues have been considered. If we could do everything at once we'd have a spec instantly. :) Perhaps also worth noting that there's already been a quite epic amount of discussion of LONGDESC, if you care to search the archives. I suppose the text might be more accurate if it said yet been decided. A rough summary of the currently dominant view in WHATWG would be that visible descriptions are more useful than invisible descriptions and that in any case LONGDESC is poisoned by real-world abuse ( http://blog.whatwg.org/the-longdesc-lottery ). -- Benjamin Hawkes-Lewis Just a random thought (not a major discussion point afaic): As I understand it, best-practice would now dictate that the image is simply explained in the actual content. I agree with this on the most part, but I can image the explanation and the image being seperated in distance from each other. Would it be helpfull for screenreaders to include a anchor-point on the image that points towards the explanatory text in such cases (which COULD be done with the longdesc), or would you think that be overkill? Bert
Re: [whatwg] usemap= and related issues
On Mon, 1 Dec 2008, Jonas Sicking wrote: Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks mode things spread into code that I work on ;) ). If no other browser is doing it in standards mode either I'm more than happy to not have it in the spec. The spec is including quirks-mode requirements; do other browsers do it in quirks mode? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 1 Dec 2008, Jonas Sicking wrote: Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) width/height on video doesn't stretch, so that you can play videos of varying aspect ratios in the same surface without rendering issues. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Dec 1, 2008 at 12:37 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 1 Dec 2008, Jonas Sicking wrote: Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) width/height on video doesn't stretch, so that you can play videos of varying aspect ratios in the same surface without rendering issues. Ah, makes sense. Wasn't there once upon a time a CSS draft that let you specify how replaced elements should stretch in situations like this? So you could choose if it should zoom-to-fit (like it sounds like video does) or stretch-to-fit (like img does), zoom-to-fill as well as a few other things. I can't seem to find it though... I guess my point is, can we let CSS deal with this? If it indeed needs to be dealt with. / Jonas
Re: [whatwg] usemap= and related issues
Ian Hickson wrote: On Mon, 1 Dec 2008, Jonas Sicking wrote: Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks mode things spread into code that I work on ;) ). If no other browser is doing it in standards mode either I'm more than happy to not have it in the spec. The spec is including quirks-mode requirements; do other browsers do it in quirks mode? As I already said above, neither Opera, Safari or IE8 have the same behaviour. I tested both quirks and standards mode. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Video metadata attributes clarification
On Tue, 25 Nov 2008, Matthew Gregan wrote: I'm seeking clarification on when the videoWidth and videoHeight attributes are expected to become valid. Actually it'd probably be useful to have all of the metadata attributes listed explicitly somewhere so that it's clear exactly what is expected to be valid when readyState is HAVE_METADATA. I've revamped the requirements around that section to make it clearer. Please let me know if there are still ambiguities. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 1 Dec 2008, Philip J�genstedt wrote: Now that the pixelratio override is gone, shouldn't the influence of pixel aspect ratio on the layout be removed also? It is, isn't it? What did I leave in? I would prefer if the default were to stretch to fit if both width/height are given, just like for img. Letterboxing/pillarboxing should be the special case, is the idea that we should have the equivalent of SVG:s preserveAspectRatio either via CSS or HTML? We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
Ian Hickson schrieb: You can jump to a position that's a fraction of the whole clip by setting 'currentTime' to a fractional multiple of 'duration'. Right, I was thinking of what happens if no duration could be determined with acceptable effort. However, by now I happen to think that determining the duration where possible (even if its not completely straightforward) is useful enough to require it. - make currentTime readonly, still have it report playback position in absolute time. This information should be available in all media formats due to timestamps in the stream. - introduce a seek() method, taking a relative value ranging from zero to one. This allows both accurate seeking if the duration is known and less precise seeking otherwise if only the length of the file is known in storage units. This is still way better than not being able to seek at all. Why should currentTime be readonly? Because seek() would already to trigger seeking (is there a different usecase for a writeable currentTime?). Anyway, I don't suggest paying attention to my proposals anymore - after some consideration and experimentation I don't think they improve anything ;-) On Tue, 25 Nov 2008, Maik Merten wrote: This applet does not seek to the end of the stream to retrieve a timestamp there. It should. :-) And it now does :-) http://svn.wikimedia.org/viewvc/mediawiki/trunk/cortado/src/com/fluendo/player/DurationScanner.java?view=log Byte-position based estimates etc. etc. just didn't work out, so I finally gave in ( ;-) ) and wrote the ~200 lines of code to actually Do Things Approximately Properly(tm). Seems I saw an implementation problem where none exists. On Wed, 26 Nov 2008, Chris Double wrote: I won't be estimating the duration - the user experience of a fluctuating duration is terrible. For now for Ogg files, I'm seeking to the end and getting the duration. I may check for X-Content-Duration which I believe mod_annodex and soon oggz-chop support. Cool. I now finally arrived at the same conclusions. Maik
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. why should this be different for images and video? there are ways to center elements inside a playback area. how would i stretch a video if its always displayed in the aspect ratio from the container, i.e. to have an animation where the video is a dot first, than gets stretched to a thin 5 x 480 element and than unfolds to its full dimensions 640x480. +1 for stretch to fit if both width/height. j
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: On Mon, 1 Dec 2008, Philip Jgenstedt wrote: Now that the pixelratio override is gone, shouldn't the influence of pixel aspect ratio on the layout be removed also? It is, isn't it? What did I leave in? Video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the aspect ratio of the video, the video will be shown letterboxed or pillarboxed. Areas of the element's playback area that do not contain the video represent nothing. I would prefer if the default were to stretch to fit if both width/height are given, just like for img. Letterboxing/pillarboxing should be the special case, is the idea that we should have the equivalent of SVG:s preserveAspectRatio either via CSS or HTML? We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. I'm having a hard time seeing how this is a use case for video and not for img. If one wants the intrinsic width/height to be used, then simply don't set width/height. Otherwise, just setting just one of width/height or using CSS max-width/max-height should do the trick. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- img src=circle.jpg width=400 height=400 !-- circle -- img src=circle.jpg width=400 height=300 !-- oval -- I think it would be much more consistent if these elements behaved in the same way. As it stands, after the pixelratio was removed, there is no way to display a circle as an oval or vice versa, which means it is both impossible to fix an incorrect aspect ratio or to stretch the video for some other purpose. So, what is the difference between images and moving images? -- Philip Jägenstedt Opera Software
Re: [whatwg] Citing multiple blockquote elements in HTML5
Tab Atkins Jr. ha scritto: [[off list]] Well, in fact, the above could be done as well by 'playing' with anchors (but is it still possible to set an anchor somewhere in the document, such as a id=foo /? I haven't found examples for that, perhaps I'm missing something...). Yes, a hash link (a href=#foo) will scroll to the element with an id=foo. If coding properly, you'll virtually *never* use an a for an actual *anchor*, but rather will target the most semantically appropriate element, such as a heading or a container with the appropriate @id. ~TJ Thanks! That's what I was missing in the specicification (I should give it a more accurate reading). Does it applies to every element, covering the cite element too? If so, there is no need for new attribute to relate a quoted content to its cited source (especially to relate several quotations to a single, or a main, complete reference), something like: pAn interesting element is the codelt;citegt;/code element. It's definition is: q cite=#citeThe |codecite/code| element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing./q/p pThe codecite/code element semantics finds a good placing inside a bibliographic citation, but only refers to the title of the work, not to the entire citation. In fact, it is sayd: q cite=#citeThe |codecite/code| element is obviously a key part of any citation in a bibliography, but it is only used to mark the title/q [...]/p [...] pA complete reference for the codecite/code element is found in WHATWG a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/;citeHTML 5/cite/a draft reccomendation, section a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-cite-element;cite id=cite4.6.3 The codecite/code element/cite/a should work fine, while in a scientific paper something like ...a href=#whref[whnt02]/a... might be an instance of: pb[whnt02]/b: cite id=whrefA new theory on White Holes: universe regeneration proved./cite, John Doe and Jack Someone, 2013, Science Paper Hall, IBAN:'example_iban_code'/p in a similar way as ... a href=#jdJohn Doe/a... is an instance of: pThe name dfn id=jdJohn Doe/dfn is the one commonly used to indicate a person whose identity is unknown; may be found in some examples to indicate a generic person involved in some context, to indicate whoever else could be involved too, or to focus the attention on the context itself or its related subject, despite any real person involved or the likelyhood for the facts to happen./p In conclusion, what I was suggesting is yet possible, if I'm not misanderstandig (again?), without any need for additional attributes. The reverse realtionship (from a cite to one or more q/blockquote), instead, might be more difficoult, but I agree with Ian Hickson that some 'real world' need should arise before addressing such. BR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Meetic: il leader italiano ed europeo per trovare l'anima gemella online. Provalo ora Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8291d=1-12
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. I'm having a hard time seeing how this is a use case for video and not for img. If one wants the intrinsic width/height to be used, then simply don't set width/height. Otherwise, just setting just one of width/height or using CSS max-width/max-height should do the trick. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. img src=circle.jpg width=400 height=400 !-- circle -- img src=circle.jpg width=400 height=300 !-- oval -- I think it would be much more consistent if these elements behaved in the same way. What is the use case for wanting a video to be stretched? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 18:19 +0100, Lachlan Hunt wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. I'm having a hard time seeing how this is a use case for video and not for img. If one wants the intrinsic width/height to be used, then simply don't set width/height. Otherwise, just setting just one of width/height or using CSS max-width/max-height should do the trick. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. The strange part isn't that the video is pillarboxed, but that it's impossible to not do it and that it's inconsistent with img. img src=circle.jpg width=400 height=400 !-- circle -- img src=circle.jpg width=400 height=300 !-- oval -- I think it would be much more consistent if these elements behaved in the same way. What is the use case for wanting a video to be stretched? The use case for stretching moving images (video) is exactly the same as for stretching animations (img src=animation.gif) or static images (img src=static.jpg). While I think that fixing incorrect aspect ratio is the most probable use, consistency and generality is the real issue here. With an image of size 800x600 it's possible to display at any size, even those which don't match the aspect 4:3. With moving images (video) we can't influence it at all. The previous solution was the pixelratio attribute, but I have 2 other possible solutions: video src=4x3.mpg width=1920 height=1080 keepaspect The video would be pillarboxed. video src=4x3.mpg width=1920 height=1080 The video would be stretched and have incorrect aspect, just like img src=4x3.jpg width=1920 height=1080 This way it's easy to stretch or to keep aspect, whichever you want. Given the number of people who watch 4:3 video stretched to a 16:9 display without even noticing/caring that the aspect ratio is wrong, I don't think we can trust that the aspect ratio of all videos is always going to be correctly encoded and simple say that this should be fixed by reencoding the video -- that's not even an option if the source file is not available and reencoding is good for quality. But to reiterate, this is mainly about generality and consistency. Are there any other suggestions? Could this perhaps be done with CSS so that the same thing could be done with img? It is in fact rather difficult to scale something to fit inside a box using only CSS right now. It would be rather sad to see img and video be so inconsistent when -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 1 Dec 2008 [EMAIL PROTECTED] wrote: why should this be different for images and video? Why should it be the same, other than consistency? I wouldn't make img stretch either if I was defining it today. Allowing stretching of images enabled a lot of problems, such as images at the wrong ratio, presentational use of images, etc. there are ways to center elements inside a playback area. Why makes things more complicated than necessary? how would i stretch a video if its always displayed in the aspect ratio from the container, i.e. to have an animation where the video is a dot first, than gets stretched to a thin 5 x 480 element and than unfolds to its full dimensions 640x480. Animations of that nature should be done either using SVG or CSS transforms, not at the HTML level. On Mon, 1 Dec 2008, Philip J�genstedt wrote: Now that the pixelratio override is gone, shouldn't the influence of pixel aspect ratio on the layout be removed also? It is, isn't it? What did I leave in? Video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the aspect ratio of the video, the video will be shown letterboxed or pillarboxed. Areas of the element's playback area that do not contain the video represent nothing. That's what it said before we added pixelratio=. We definitely don't want to stretch the video. One of the important use cases if having a video playback area and then playing videos with different aspect ratios in that playback area. It should all just work. I'm having a hard time seeing how this is a use case for video and not for img. I don't understand how it's a use case for img either. If one wants the intrinsic width/height to be used, then simply don't set width/height. Otherwise, just setting just one of width/height or using CSS max-width/max-height should do the trick. The idea is that generally you don't want the intrinsic size to be used, you want a consistent size to be used, and you would set it from CSS. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- img src=circle.jpg width=400 height=400 !-- circle -- img src=circle.jpg width=400 height=300 !-- oval -- I think it would be much more consistent if these elements behaved in the same way. I don't think consistency here is an issue. Or if you like, consider it as being consistent with iframe: iframe src=circle.html width=400 height=400 !-- circle -- iframe src=circle.html width=400 height=300 !-- pillarbox -- As it stands, after the pixelratio was removed, there is no way to display a circle as an oval or vice versa, which means it is both impossible to fix an incorrect aspect ratio or to stretch the video for some other purpose. Right; we established that the use cases for stretching the video were not convincing, that's why I removed pixelratio=. On Mon, 1 Dec 2008, Lachlan Hunt wrote: This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. True. On Mon, 1 Dec 2008, Pierre-Olivier Latour wrote: I can only think of the case when you need to post-fix a video which wasn't encoded with the proper pixel aspect ratio. And we already covered the likelihood of encountering this case extensively. So I guess what's left is purely a convention decision: - should video behaves like img by default and have a special attribute to scale proportionally, - or should video scale proportionally by default, and maybe have some way of defining a stretching behavior? Eric I would recommend the later because based on past experience, users often specify the wrong width height for the element, and if we stretch by default, then we would often fall off the fast path of the media engine (scaling anamorphically can be very expensive). At the end of the day, being consistent with img wouldn't be worth the potential other issues. Regarding the stretch attribute, we should have this functionally available to users but preferably at the CSS level. I agree that something like stretch or pixelratio should probably be added in a future version, but since we just removed pixelratio= I don't think it is something we want to add now. On Mon, 1 Dec 2008, Martin Atkins wrote: It would also be useful if this mechanism were available for images. A bunch of times I've written code to proportionally scale images to
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: The use case for stretching moving images (video) is exactly the same as for stretching animations (img src=animation.gif) or static images (img src=static.jpg). Consistency is not a use case. For images, we're constrained by backwards compatibility requirements to stretch them, rather than keep aspect ratios, regardless of what use cases there may or may not be for doing so. For video, we are not constrained by such backwards compatibility and we have the opportunity to specify the most rational alternative as the default. While I think that fixing incorrect aspect ratio is the most probable use, consistency and generality is the real issue here. Given that the pixelratio attribute was dropped in part due to a lack of compelling use cases, I don't think the same use case will be compelling for this either. If there are real use cases for stretching video, then they should be judged on their own merits, rather than just falling back to the consistency argument. With an image of size 800x600 it's possible to display at any size, even those which don't match the aspect 4:3. With moving images (video) we can't influence it at all. The previous solution was the pixelratio attribute, but I have 2 other possible solutions: video src=4x3.mpg width=1920 height=1080 keepaspect The video would be pillarboxed. Retaining the aspect ratio needs to be the default because based on experience with video on the web today, e.g. on YouTube, and also based on the behaviour of common media players, like VLC, QuickTime, Windows Media, etc. When a user resizes their video player, the video generally maintains the aspect ratio and gets black bars; (or in QuickTime's case, the window size is constrained by the video's aspect ratio). There are menu options in VLC, and possibly others, to set the aspect ratio of a video to a selection of common aspect ratios, but there is no arbitrary scaling (at least, not that I'm aware of). video src=4x3.mpg width=1920 height=1080 The video would be stretched and have incorrect aspect And if a user chooses to put the video in full screen, then what? Should it maintian that incorrect aspect ratio? Should it stretch to fill the whole screen, regardless of what type of monitor the user is using, or should it use the video's default aspect ratio? Given the number of people who watch 4:3 video stretched to a 16:9 display without even noticing/caring that the aspect ratio is wrong, While I'm aware that there are such people, largely because they don't know how to configure their TV's properly or because their TV's are broken by design, there are many others who do notice the difference (including myself). From my experience, stretching a 4:3 picture to fill a 16:9 screen is enough to make people on the screen look weird and out of proportion. It's less noticeable with cartoons, but in general, it's very noticeable and annoying. We should inflict such annoyances upon end users if it avoidable; at least not by default. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Citing multiple blockquote elements in HTML5
On Mon, 1 Dec 2008, Calogero Alex Baldacchino wrote: Yes, a hash link (a href=#foo) will scroll to the element with an id=foo. If coding properly, you'll virtually *never* use an a for an actual *anchor*, but rather will target the most semantically appropriate element, such as a heading or a container with the appropriate @id. Thanks! That's what I was missing in the specicification (I should give it a more accurate reading). Does it applies to every element, covering the cite element too? See: http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid Let me know if that doesn't address your use case. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
BTW, using CSS transforms (not a standard yet, but implemented in Webkit and Gecko now), you can stretch video (or anything else) any way you want. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. Regards, Silvia.
Re: [whatwg] video tag: pixel aspect ratio
Am Dienstag, den 02.12.2008, 11:02 +1100 schrieb Silvia Pfeiffer: I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. Better make it CSS – this is as presentational as it can get. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 23:07 +0100, Lachlan Hunt wrote: Given the number of people who watch 4:3 video stretched to a 16:9 display without even noticing/caring that the aspect ratio is wrong, While I'm aware that there are such people, largely because they don't know how to configure their TV's properly or because their TV's are broken by design, there are many others who do notice the difference (including myself). From my experience, stretching a 4:3 picture to fill a 16:9 screen is enough to make people on the screen look weird and out of proportion. It's less noticeable with cartoons, but in general, it's very noticeable and annoying. We should inflict such annoyances upon end users if it avoidable; at least not by default. The point wasn't that it is OK for UA:s to distort video because there are people who don't notice, but that some people do/will encode video with the wrong aspect ratio without noticing/caring. The general consensus seems to be that this isn't worth the effort fixing. But in any event, if a CSS solution is in fact possible that would be much better than any video-specific solution. I don't think CSS transforms can do it though, unless someone can give an example? -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Dec 2, 2008 at 11:02 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- This is effectively how YouTube behaves now with their recent change to a widescreen player. It would look terrible if 4:3 videos were stretched to fill the 16:9 viewport, instead of just using black bars on the side. Even before when they were still using a 4:3 player, widescreen videos were rendered as letterbox. Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. I checked this out a little more, since I remembered using the JW player for some flv videos and they were stretched to the size of the player no matter what their original encoded size. According to this thread http://www.jeroenwijering.com/?thread=13766 it depends on whether the video metadata contains the original width/height of the video. If it doesn't have that, the JW player stretches to whatever is given. Jeroen might have changed that by now, since it seems that many players now decode a few frames of video to determine the original width/height of the video if this information is not provided in the video metadata. There are tools to include such metadata into the video headers for the different video formats that exist and I am sure someone like YouTube will make sure that metadata is available. However, I would not expect the common user to be clever enough to make sure their videos provide this data. This raises a few questions: * Do we want to prescribe the use of the width/height metadata for determining the video size inside the viewport? * How often is the widht/height metadata in videos encoded with wrong values? * Do we want to force all video players to decode a few frames and get the correct width/height values to then adapt to the viewport? * Do we have use cases for overriding correct aspect ratio displays by users? (and should that then go into a CSS control?) I would much prefer the default video display to get it right inside a viewport, than to risk relying on users to get the aspect ratio right. Also, the viewport approach makes it easier to have a consistently sized video player rather than adapting the video player to the video's actual size and thus potentially constantly switching between 4:3 and 16:9. So (contrary to what I wrote just before), I think the attribute should not be a keepaspectratio attribute but rather something like fillviewport and it should probably be a CSS attribute. Cheers, Silvia.
Re: [whatwg] video tag: pixel aspect ratio
On Tue, 2 Dec 2008, Silvia Pfeiffer wrote: Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. Yeah, it's really annoying. :-) I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. I think that this belongs in CSS, for the reason Nils gave: On Tue, 2 Dec 2008, Nils Dagsson Moskopp wrote: Better make it CSS – this is as presentational as it can get. On Tue, 2 Dec 2008, Silvia Pfeiffer wrote: This raises a few questions: * Do we want to prescribe the use of the width/height metadata for determining the video size inside the viewport? We already do. * How often is the widht/height metadata in videos encoded with wrong values? Relatively often, IMHO, that's why I wanted pixelratio=. But we've established that this is not something we're addressing in v1. * Do we want to force all video players to decode a few frames and get the correct width/height values to then adapt to the viewport? We already force them to decode the end of the stream to get the right duration, having them decode one frame so that they can render that frame seems reasonable enough. * Do we have use cases for overriding correct aspect ratio displays by users? (and should that then go into a CSS control?) There are always use cases for presentational effects, and those indeed belong in CSS. I would much prefer the default video display to get it right inside a viewport, than to risk relying on users to get the aspect ratio right. Indeed. Also, the viewport approach makes it easier to have a consistently sized video player rather than adapting the video player to the video's actual size and thus potentially constantly switching between 4:3 and 16:9. Right. So (contrary to what I wrote just before), I think the attribute should not be a keepaspectratio attribute but rather something like fillviewport and it should probably be a CSS attribute. Agreed. On Tue, 2 Dec 2008, Philip J�genstedt wrote: The point wasn't that it is OK for UA:s to distort video because there are people who don't notice, but that some people do/will encode video with the wrong aspect ratio without noticing/caring. The general consensus seems to be that this isn't worth the effort fixing. Right, that's why we dropped pixelratio=. :-) But in any event, if a CSS solution is in fact possible that would be much better than any video-specific solution. I don't think CSS transforms can do it though, unless someone can give an example? Well, CSS transforms don't officially exist yet, but you could use a scale() or scaleX() transform: http://webkit.org/specs/CSSVisualEffects/CSSTransforms.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson [EMAIL PROTECTED] wrote: For the few servers that don't support seeking, duration is not available. Note that that is non-conforming at the moment. You have to have a duration available (though it can be +Infinity if you think that the resource is a stream, and can be an estimate, so long as you keep updating it as your information gets better.) I think the spec should be changed to allow duration to be NaN in the case where it cannot be determined. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] usemap= and related issues
On Mon, Dec 1, 2008 at 4:37 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 1 Dec 2008, Lachlan Hunt wrote: Ian Hickson wrote: On Mon, 1 Dec 2008, Jonas Sicking wrote: Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks mode things spread into code that I work on ;) ). If no other browser is doing it in standards mode either I'm more than happy to not have it in the spec. The spec is including quirks-mode requirements; do other browsers do it in quirks mode? As I already said above, neither Opera, Safari or IE8 have the same behaviour. I tested both quirks and standards mode. In that case, it truly seems like something where Gecko should just be simplified. Jonas: are there pages that depend on this? If we could remove that quirk, that'd be awesome... I don't know more than what's in that bug [1], but if IE8 indeed has dropped this quirk then I'm more than happy to do the same in firefox. / Jonas [1] https://bugzilla.mozilla.org/show_bug.cgi?id=264624
Re: [whatwg] usemap= and related issues
On Mon, 1 Dec 2008, Jonas Sicking wrote: Jonas: are there pages that depend on this? If we could remove that quirk, that'd be awesome... I don't know more than what's in that bug [1], but if IE8 indeed has dropped this quirk then I'm more than happy to do the same in firefox. Ok. I'm going to go forward on the assumption that we don't need this quirk in HTML5. Let me know if this should change. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media elements: Relative seeking
At 2:06 + 2/12/08, Ian Hickson wrote: On Tue, 2 Dec 2008, Chris Double wrote: On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson [EMAIL PROTECTED] wrote: For the few servers that don't support seeking, duration is not available. Note that that is non-conforming at the moment. You have to have a duration available (though it can be +Infinity if you think that the resource is a stream, and can be an estimate, so long as you keep updating it as your information gets better.) I think the spec should be changed to allow duration to be NaN in the case where it cannot be determined. We removed some other features (e.g. bufferedBytes and totalBytes) because implementors said they would always provide accurate values in the buffered and duration attributes. If we allow duration to be NaN, then we'd have to re-add the other features again. what is the duration of an indefinite stream (e.g. live or simulated live)? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] media elements: Relative seeking
On Tue, Dec 2, 2008 at 3:06 PM, Ian Hickson [EMAIL PROTECTED] wrote: We removed some other features (e.g. bufferedBytes and totalBytes) because implementors said they would always provide accurate values in the buffered and duration attributes. If we allow duration to be NaN, then we'd have to re-add the other features again. It's not possible to always provide accurate values for duration - we've already discussed that and you suggested estimating. I don't see that as an accurate value. Can you link to the post where implementors said they would always provide accurate values? The only accurate value I can provide with Ogg is the exact duration if the http server supports byte range requests, or some other out of band duration metadata (X-Content-Duration, etc). Without byte range requests, accurate duration is not possible. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] media elements: Relative seeking
On Tue, 2 Dec 2008, Chris Double wrote: It's not possible to always provide accurate values for duration - we've already discussed that and you suggested estimating. I don't see that as an accurate value. The spec does allow for estimations and provides for the estimate being revised dynamically. Can you link to the post where implementors said they would always provide accurate values? The attributes were removed based on: http://lists.w3.org/Archives/Public/public-html/2008Nov/0131.html The only accurate value I can provide with Ogg is the exact duration if the http server supports byte range requests, or some other out of band duration metadata (X-Content-Duration, etc). Without byte range requests, accurate duration is not possible. That's fine, just update it as you get more info. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008, Michael A. Puls II wrote: On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: What about the method=POST case where the query string is kept? form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. O.K., but in the case of the + that's in the mailto URI in the action attribute, the author means a '+' and not a space (they're allowed to be left in raw form in a mailto URI). If it gets sent to a server, the + will be treated as a space, which is not what is intended. I actually can't find where it is defined that the + in an HTTP URI represents a space. (I can find where it says that a space is to be converted into a +, but not the other way around.) My understanding, though, is that the convention that + represents a space is not part of the URI syntax, but part of the syntax of the format used to encode the data into the URI, which for HTTP URIs is generally application/x-www-form-urlencoded. But nothing stops this format from being used elsewhere, e.g. in the body of an e-mail or a POST submission. The workaround is of course for the author to make sure to encode that + as %2B (or never use anything but action=mailto:; even for POST). But, for good measure, it seems like the UA should fix that if the + will ever end up in an HTTP URI. I don't follow. Of course right now, browsers only pass the data as a mailto URI to an email program, so the + from the query string will be a + and come out fine in the compose window. As for spaces in form control values coming out as + (for POST) in a programs's body field, that's not as big of a deal as there's no use-case to *see* any of the data *like that* anyway. But it does seem incorrect to encode mailto spaces as + though. I don't follow. However, if for POST, if everything after 'mailto:' in the action attribute was dropped (like get) and all you ever had was mailto:?body=encoded_stuff that was POSTed, then the spec could say that the value you might see in the body field represents *HTTP* url encoded data. We can't drop everything, because then you'd lost the Subject: line, etc. Or, the spec could say that if the protocol in the action attribute is mailto:, +s in the action attribute have to be encoded as %2B and spaces in the action attribute have to be encoded as %20. Then, the validator can catch that and the spec can say (for POST), that the body hvalue that gets generated from the form represents *HTTP* form data. Then, it'll be clear why +s in the value are represented as + instead of %20. I don't follow here either. Or, if it's O.K. for a UA's URI normalizer/resolver to take action=mailto:?subject=1+2 3 and normalize that to action=mailto:?subject=1%2B2%203; for use with the form's .action getter, I guess that might solve it to. I think we may be talking at cross-purposes... which requirements in the spec are you referring to? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
