Re: [whatwg] video ... script race condition
On 17 May 2011, at 09:04, Philip Jägenstedt wrote: Or do you mean a spec bug? I meant a spec bug :)
Re: [whatwg] video ... script race condition
Hi all, Since this is *my* code that we're talking specifically about, I'd like to repeat Glenn's point that this is not sloppy code (the cheeky shit), and that the /everyman/ developer is going to think that attaching an event is perfectly legal and will expect it to work. Now you're right, whoever pointed out the 7am alarm example, if you attach the event too late, then you'll miss the boat. However, it's a chicken an egg situation. You don't have the DOM so you can't attach the event handler, and if you do have the DOM, the damn event has fired already. What's the fix? Well, the work arounds are certainly viable, again from an everyman developer point of view: 1) Attach higher up, on the window object and listen for the canplay/loadedmetadata/etc and check the event.target 2) Attach an inline event handler (not nice, but will do) The fix? Since ultimately we have exactly the same potential bug with image load events, is to update the specification and make it clear: that depending on the speed of the connection and decoding, the following xyz events can fire **before** your script runs. Therefore, here's a couple of work arounds - or just be aware. Any objections? At the same time, does someone want to raise this as a bug? Cheers folks, Remy Sharp / everyman developer :) On 16 May 2011, at 08:20, Simon Pieters wrote: On Sun, 15 May 2011 19:11:09 +0200, Glenn Maynard gl...@zewt.org wrote: On Sat, May 14, 2011 at 11:49 AM, Eric Carlson eric.carl...@apple.comwrote: It seems to me that the right way to fix the problem is let people know it is sloppy code, not to figure out a way to work around it. The basic problem is that it isn't sloppy code: it's correct for almost all events. It's just wrong for events that are fired as part of loading, which is what makes it so easy to get wrong. It also means that these events don't work well with deferred scripts. For the simple cases I'd probably do: video.addEventListener(canplay, func, false); if(video.readyState = HAVE_FUTURE_DATA) func.apply(video); // missed the first one The state can have changed before the event has actually fired, since state changes are sync but the events are queued. So if the script happens to run in between then func is run twice. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 -- Simon Pieters Opera Software
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 14 Oct 2009, at 11:06, Remco wrote: 2. Use legend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use dt/dd, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. So what you'd expect is that #3 would take about 4 years to completely fix itself, and #2 would take about 5 years. With such a small difference, I'd just choose the best option in the long term. Option #2 affects every major browser currently on the market (i.e. it's broken) - I'm excluding betas. That's Opera, Firefox, IE, Safari Chrome. Option #3 only affects IE7 and below - which is 30+% of the market, but at the very least IE8 has it right - which means that (I would hope) future versions of IE won't have this bug. I'd be amazed if IE7 is flushed out of the major market share (20% since Firefox is around that mark) within 5 years (personally I'm expecting to be around for longer) - rather than amazed, going by the growth rates (of other browsers), I'm saying it won't happen. So to say that *all* the browsers that we currently have are going to be down to a insignificant market share, that we can sensibly use legend is going to much more than 5 years. http://en.wikipedia.org/wiki/Usage_share_of_web_browsers With that in mind, and having to choose the lesser of two evils (though semantically I know which I prefer), option #3 is the only sensible choice if you want authors to use these elements in a reasonable amount of time. Remy Sharp.
[whatwg] Multipage spec
I'm sure someone is aware, but the multipage spec is broken, or even not there anymore. http://www.whatwg.org/specs/web-apps/current-work/multipage/ Personally I find the multipage much faster to work with, and I'm sure I'm not alone. So hopefully it can be brought back to life some time soon? Cheers, Remy Sharp
Re: [whatwg] small element should allow nested elements
On 14 Aug 2009, at 10:09, Ian Hickson wrote: I wouldn't bother wrapping any of the above as small print. If you're structuring this enough that you have numbered lists and paragraphs and everything, then it's either not small print, or it shouldn't be. As Aryeh said, my experience has been the inverse, this is small print. I've got the terms and conditions for a competition, which is small print for the whole thing. Currently I'm manually wrapping every sentence in a small tag (as per my example). For example, the BBC's web site is using the 62.5% rule, then by default pages are shown in 1.2em. The exception being their terms pages, which overrides the font size to 1em in a terms.css style sheet. This is because they want the text to appear as small print. BBC Terms: http://www.bbc.co.uk/terms/ Random blog post on the BBC (most, if not all pages are the same font size): http://www.bbc.co.uk/blogs/thereporters/robertpeston/2009/08/what_rbss_results_say_about_qe.html They're using CSS to visually create the small print effect on a large amount of text. From my understanding of the HTML 5 spec, the right semantics to use is the small element, but if they used it on their existing terms page, in the way that the spec current outlines it would bloat the page with the extra nested small element. Wrapping the entire block in small (or individual blocks) would be much more maintainable, and it would give the copy the right semantic meaning. Is that correct? Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. Is there any record of these issues. I know of 1 rendering issue that Firefox has with nesting the section element inside the a element (but I'm sure you're referring to previously solved issues). I'd be happy to go through those issues and see if I can run tests against the small element through each of the browser engines to see if the issues still apply to small element. Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] small element should allow nested elements
Here's the actual example I'm working with: http://2009.full-frontal.org/ticket-draw (at the bottom of the page) You can see that I've had to wrap each inner li element, and also that the li bullet sizes don't match that of the text. It seems logical to me to wrap the entire ol element in the small tag. Remy Sharp On 15 Aug 2009, at 12:29, Smylers wrote: Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;Cs./ a./small /p
[whatwg] small element should allow nested elements
Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] small element should allow nested elements
I should add, another argument for using small to wrap, is that without it, on a list element, the numerals in the list are larger than the the small print text - because the small element is on the inner HTML rather than the entire element (which does effect the numeric bullets too). Remy Sharp On 7 Aug 2009, at 14:19, Remy Sharp wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
[whatwg] Drag and drop - keyboard support
Hi, I've been running quite a few tests with the Drag and Drop API, and more recently I was looking at creating an accessible demo of DnD. Plugging ARIA support wasn't a problem, but keyboard support was a no goer. I tried triggering the dragstart event from the keyboard - which was fine, except that I couldn't get the dataTransfer object in there (it was null), so it meant the whole drag operation couldn't be triggered from the keyboard. Unless I'm missing something, keyboard accessibility has been overlooked for DnD. It's been raised once before, and I agree with some of the points raised in the url below, but I *can* get around them with scripting, whereas keyboard support flat out doesn't work. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020981.html I'd like to know whether this is being considered anywhere? I wondered if a copy and paste operation via the keyboard could be used to solve the keyboard DnD issue - in that coping on the :active element would trigger the dragstart event, and pasting from the keyboard could trigger the drop event on the current active element (that the user would tab to) (this idea was entirely inspired by Aron's post). Is this a viable option? Cheers, Remy Sharp Left Logic
