Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On October 14th, Hixie wrote: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 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. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without 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. It looks like the workaround for #3 isn't quite as arduous as it first appeared: http://blog.jeroenvandergun.nl/7-html5-figure-and-details-do-not-break-in-ie Wrapping the details or figure element in a div seems to fix IE's parsing. It's still not ideal but it's much better than the conditional comment object hackery. (and again, this only relates to versions of IE before IE8) So, on balance, #3 is looking more reasonable than #2 (which fails in a lot more browsers). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Wed, 14 Oct 2009, Michael(tm) Smith wrote: Ian Hickson i...@hixie.ch, 2009-10-14 03:41 +: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 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. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without 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. In terms of the Priority of Constituencies principle, it'd seem to me that between #2 and #3, #2 will -- in the long term -- ultimately have lower costs and difficulties for authors, though higher costs and difficulties for implementors in the short term. I would think a big red flag ought to go up for any proposed solution that we know will lead to introducing complicated and elaborate hacks into new content. For one thing, we know from experience that due to cargo-cult copy-and-paste authoring, such hacks have a tendency to live on in content for years after the need for them in widely used UAs has disappeared. We tried legend, and the complaints were more concrete than those for dt/dd. Unless there's a really compelling reason, I don't really want to flip-flop back to the legend idea. On Wed, 14 Oct 2009, Dean Edwards wrote: On 14/10/2009 04:41, Ian Hickson wrote: On Tue, 29 Sep 2009, Dean Edwards wrote: It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. ...and except forcanvas which will be slow or not work in IE for the forseeable future, and the drag and drop model's draggable attribute which will only work in new browsers, or the new controls which will look like text fields in legacy UAs, or... how isdetails different? The other things you mentioned don't work but don't break anything. Using details can potentially break entire pages. style scoped can break entire pages. Using any of the new APIs can too. Using draggable can make something work in one browser but do something quite different in another, potentially with poor behaviour. There are workarounds for all these issues, some are more painful or risky than others. I think it's not significantly more difficult to educate authors about detailsdt hacks than about the other hacks. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) We have more than a dozen elements whose names would be appropriate here. Inventing entirely new elements to do the same thing again just to work around a very short-term problem is just silly. I don't think it is silly to prevent severe rendering problems in 30% of installed browsers. Consider what this argument would sound like 30 years from now. On Wed, 14 Oct 2009, Remco wrote: 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. I think the numbers are more like 10 years for #2 and 5 years for #3. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
Ian Hickson i...@hixie.ch, 2009-10-14 03:41 +: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 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. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without 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. In terms of the Priority of Constituencies principle, it'd seem to me that between #2 and #3, #2 will -- in the long term -- ultimately have lower costs and difficulties for authors, though higher costs and difficulties for implementors in the short term. I would think a big red flag ought to go up for any proposed solution that we know will lead to introducing complicated and elaborate hacks into new content. For one thing, we know from experience that due to cargo-cult copy-and-paste authoring, such hacks have a tendency to live on in content for years after the need for them in widely used UAs has disappeared. http://www.w3.org/TR/html-design-principles/#priority-of-constituencies -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 14/10/2009 04:41, Ian Hickson wrote: On Tue, 29 Sep 2009, Dean Edwards wrote: It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. ...and except forcanvas which will be slow or not work in IE for the forseeable future, and the drag and drop model's draggable attribute which will only work in new browsers, or the new controls which will look like text fields in legacy UAs, or... how isdetails different? The other things you mentioned don't work but don't break anything. Using details can potentially break entire pages. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) We have more than a dozen elements whose names would be appropriate here. Inventing entirely new elements to do the same thing again just to work around a very short-term problem is just silly. I don't think it is silly to prevent severe rendering problems in 30% of installed browsers. As far as I can see the options are as follows: 1. Drop support fordetails andfigure for now, revisit it later. 2. Uselegend, and don't expect to be able to use it in any browsers sanely for a few years. 3. Usedt/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. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without 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. If we go with #3, I can always add a Best viewed with Firefox badge to my web sites. That will solve the problem. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Wed, Oct 14, 2009 at 05:41, Ian Hickson i...@hixie.ch wrote: As far as I can see the options are as follows: 1. Drop support for details and figure for now, revisit it later. 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. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without 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. -- Remco
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.
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, 29 Sep 2009, Keryx Web wrote: 2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. On Tue, 29 Sep 2009, Dean Edwards wrote: You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. On Tue, 29 Sep 2009, Tab Atkins Jr. wrote: The third solution, of course, is just to avoid details until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). This whole thing is really much less of an issue than the legend problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. After all, we're already happy enough using divs or dls or whatever to implement that functionality. It would be nice to immediately start using the new stuff, but the timeline for when it's viable isn't so long as to be unworkable. In the meantime, we just keep doing what we're already doing. Indeed. On Tue, 29 Sep 2009, Dean Edwards wrote: It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. ...and except for canvas which will be slow or not work in IE for the forseeable future, and the drag and drop model's draggable attribute which will only work in new browsers, or the new controls which will look like text fields in legacy UAs, or... how is details different? Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) We have more than a dozen elements whose names would be appropriate here. Inventing entirely new elements to do the same thing again just to work around a very short-term problem is just silly. On Sat, 3 Oct 2009, Dean Edwards wrote: That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use details sooner. Just spell it div and don't worry about it for now. I really don't understand the sudden urgency here. All the browsers support this in their current versions to the same extent that they support, say, section; the only problem is obsolete browsers. If this is the biggest problem that you're worried about in terms of HTML5 deployment, then my job here is done. On Sat, 3 Oct 2009, Tab Atkins Jr. wrote: If we mint a new element, we pay the costs of adding yet another vaguely-heading element to add to the dozen+ we already have in the language, and what's the benefit? IE6 and IE7 will require a less invasive hack to get them to the same level of not-working that all the other browsers have. Indeed. On Sat, 3 Oct 2009, Keryx Web wrote: The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. I'd really like to use caption, but that's a lost cause. I would prefer to use legend, but people had even more short-term troubles with that than with dt/dd. If we're willing to wait, then I think the right solution is to drop details and figure for now and add them in later again with legend. But apparently there is so much demand that waiting a few more years isn't an option. On Sun, 4 Oct 2009, Keryx Web wrote: First and foremost, in dl the order is all important. Here it would not matter. In dl one may have several dd for each dt (or several dt's in a row), here one may not. You call this minor, I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? It's less bad, in that it reduces the number of elements being have to consider when trying to remember how you mark up the legend/caption of a details element. I agree that an element like caption or legend would be better. I
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-10-03 21:47, Tab Atkins Jr. skrev: Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel thatdt's semantics change betweendl anddetails. Nor do I feel they have different syntax at all -dl anddetails do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact thatdl has multiple name/value pairs whiledetails has only one, sodetails doesn't *have* to worry about ordering in the same way thatdl does. etc In what way is the SYNTAX different? We seem to agree on this: First and foremost, in dl the order is all important. Here it would not matter. In dl one may have several dd for each dt (or several dt's in a row), here one may not. You call this minor, I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? In what way is the SEMANTICS different? So, in my mind, dt/dd do *not* hold some special meaning that locks them into only ever being used in dl. dt is a heading element, nothing more, effectively equivalent to h1*. Well, that is not what the SPEC says is it? I mean, would you complain about using title or caption or label or legend... in details? Yes, I would. I am arguing in favor of introducing a new element, which would be the zero cost solution, since details is new anyway. + No hacks besides those that we already use to get details working as such in legacy browsers. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Sun, Oct 4, 2009 at 4:13 AM, Keryx Web webmas...@keryx.se wrote: I am arguing in favor of introducing a new element, which would be the zero cost solution, since details is new anyway. It's not a zero-cost solution, though. It introduces *another* nearly identical heading-type element to the language, joining the ranks of the dozen+ we already have. Trying to remember what heading-type element to use in details as opposed to in fieldset or what-have-you is a learning nightmare of a different variety. + No hacks besides those that we already use to get details working as such in legacy browsers. dt only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. I'm not certain what you mean by this. Indeed they won't have a harder time - the difficulty will be the same either way. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. Just teach dt/dd in a way that makes this easier to learn. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 04/10/2009 15:51, Tab Atkins Jr. wrote: dt only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. I'm sorry but you are really understating the problem here. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 04/10/2009 18:11, Tab Atkins Jr. wrote: On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwardsdean.edwa...@gmail.com wrote: On 04/10/2009 15:51, Tab Atkins Jr. wrote: dtonly requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. I'm sorry but you are really understating the problem here. Can you elaborate? Are there rendering problems in any other browsers? Is there something else I'm missing? Is this too many questions in a row? MSIE5-7 usage is currently between 25% and 30%. It will take a number of years before it becomes insignificant. The two hacks you mention are fairly hideous. One of them can potentially prevent other scripts from executing. We've gone full circle on this subject now. We are starting to repeat ourselves. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 03/10/2009 03:38, Tab Atkins Jr. wrote: Agreed, butdetails won't be usable at all in modern browsers (without hacking support in via js) until everyone updates. That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use details sooner. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Sat, Oct 3, 2009 at 3:51 AM, Dean Edwards dean.edwa...@gmail.com wrote: On 03/10/2009 03:38, Tab Atkins Jr. wrote: Agreed, butdetails won't be usable at all in modern browsers (without hacking support in via js) until everyone updates. That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use details sooner. But we won't be able to, really. As it stands, details doesn't work in any of the modern browsers. You are forced to use js to hack the toggling functionality in. IE6 and IE7 are slightly more broken, in that they require a relatively invasive script hack to get them to the same level of not-working that all the other browsers have. If we mint a new element, we pay the costs of adding yet another vaguely-heading element to add to the dozen+ we already have in the language, and what's the benefit? IE6 and IE7 will require a less invasive hack to get them to the same level of not-working that all the other browsers have. I can definitely understand why it's felt that that's not sufficient benefit to justify it. No modern browser gets anything out of the deal, only a pair of legacy browsers that are, finally, on their way out. And we'd be saddled with still more naming confusion regarding which of the dozen elements is appropriate in details as opposed to figure, table, section, etc. despite them all serving roughly the same purpose. A permanent cost to solve a temporary problem that will disappear on its own, and one that doesn't even *need* solving - the only benefit is that you get to change your toggle scripts to look for details rather than div class=toggle sooner. I wanna use details soon too - it gives me the warm fuzzies for some reason even if I have to hack the functionality in myself. But I can accept waiting until IE7 is irrelevant. I'm going to be doing that anyway for a number of other HTML5 features. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-10-03 00:51, Tab Atkins Jr. skrev: dt/dd only have parsing problems in IE6 and IE7. Both of them *are*, finally, actually dropping off the radar. Windows 7 will accelerate this as people upgrade with an OS that runs IE8 by default. Give it 2 years or so and most places will be able to justify ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to details type and details data, when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web webmas...@keryx.se wrote: 2009-10-03 00:51, Tab Atkins Jr. skrev: dt/dd only have parsing problems in IE6 and IE7. Both of them *are*, finally, actually dropping off the radar. Windows 7 will accelerate this as people upgrade with an OS that runs IE8 by default. Give it 2 years or so and most places will be able to justify ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to details type and details data, when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel that dt's semantics change between dl and details. Nor do I feel they have different syntax at all - dl and details do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact that dl has multiple name/value pairs while details has only one, so details doesn't *have* to worry about ordering in the same way that dl does. You see, I've authored lots of internal applications for myself and others in my company. Tree structures figure prominently, since these application are often relatively thin layers over the database structure. Looking back, I appear to be split evenly and arbitrarily between using nested dls to handle this structure and using nested headings/sections to handle it. There really doesn't appear to be much rhyme or reason behind my choice of one or the other. Either would be appropriate. The only thing I can see is that possibly the pages I saw more as lists I used dls for, while the pages I saw more as documents I used headings/sections for. So, in my mind, dt/dd do *not* hold some special meaning that locks them into only ever being used in dl. dt is a heading element, nothing more, effectively equivalent to h1*. dd is a sectioning element, nothing more, effectively equivalent (though used slightly differently) to section. Both dt and h1 declare the name for some body of data contained in dd or section. Thus using dt and dd in details to fulfill the same purpose (wrapping the name and the data) is completely natural to me. That's not to say that other solutions wouldn't also be natural, but I find nothing wrong with the status quo on semantic or usability concerns. I mean, would you complain about using title or caption or label or legend or what-have-you in details? The change in semantics and syntax would be as great or greater than dt/dd. It so happens that all of those are *worse* from a rendering perspective than dt/dd, so we've discarded them as solutions. But none of them are privileged as 'closer' to the syntax or semantics of the toggler and data elements of details. ~TJ * I know that the equivalence is not complete - h* has an effect on the document outline that dt does not. But aside from that, they're equivalent in my eyes.
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 20:08, Dean Edwards wrote: You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() On 29/09/2009 18:10, Dean Edwards wrote: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. On 29/09/2009 21:55, Keryx Web wrote: 2009-09-29 21:53, Dean Edwards wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. Can we revisit this? It seems to important to sweep under the carpet. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Fri, Oct 2, 2009 at 5:35 PM, Dean Edwards dean.edwa...@gmail.com wrote: On 29/09/2009 21:55, Keryx Web wrote: 2009-09-29 21:53, Dean Edwards wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. Can we revisit this? It seems to important to sweep under the carpet. The basic issue is that the use-case for figure and details are sorta minimal anyway - it's enough that they can justify themselves, but just barely. If we have to mint *more* new elements just to get them to work, that moves them from barely worth the effort to meh, just drop it. dt/dd only have parsing problems in IE6 and IE7. Both of them *are*, finally, actually dropping off the radar. Windows 7 will accelerate this as people upgrade with an OS that runs IE8 by default. Give it 2 years or so and most places will be able to justify ignoring IE7 (many/most sites already ignore IE6). In the meantime, we can just keep using divs to handle both of these cases, like we do right now. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 02/10/2009 23:51, Tab Atkins Jr. wrote: On Fri, Oct 2, 2009 at 5:35 PM, Dean Edwardsdean.edwa...@gmail.com wrote: On 29/09/2009 21:55, Keryx Web wrote: 2009-09-29 21:53, Dean Edwards wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. Can we revisit this? It seems to important to sweep under the carpet. The basic issue is that the use-case forfigure anddetails are sorta minimal anyway - it's enough that they can justify themselves, but just barely. If we have to mint *more* new elements just to get them to work, that moves them from barely worth the effort to meh, just drop it. If that's the way people feel then it is better to drop these elements rather than introduce potentially dangerous behaviours when using them. You say that the use cases are marginal but just as I started getting used to them I found an awesome way to use them. Now that I can't use them I feel less awesome. dt/dd only have parsing problems in IE6 and IE7. Only 30% of browsers you say? In the meantime, we can just keep usingdivs to handle both of these cases, like we do right now. So we drop two new elements for the sake of adding two more? -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Fri, 02 Oct 2009 23:51:55 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: the use-case for figure and details are sorta minimal anyway - it's enough that they can justify themselves, but just barely. Use case for figure is perhaps minimal. But details is hugely useful. It's an incredibly common thing to want to collapse and hide a section of explanatory text. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Fri, Oct 2, 2009 at 7:25 PM, Bruce Lawson bru...@opera.com wrote: On Fri, 02 Oct 2009 23:51:55 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: the use-case for figure and details are sorta minimal anyway - it's enough that they can justify themselves, but just barely. Use case for figure is perhaps minimal. But details is hugely useful. It's an incredibly common thing to want to collapse and hide a section of explanatory text. Agreed, but details won't be usable at all in modern browsers (without hacking support in via js) until everyone updates. By the time details has native functionality it'll be safe to use dt/dd in it. For now we can just keep doing what we're already doing with javascript and do this with divs (or, as I often use, dls). figure is actually worse off here, since it 'works' in modern browsers already (since it's nothing but a div with extra semantics). But, as you say, it's also much less useful in general terms than details will be. Staying with div for now won't be a big deal. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, 29 Sep 2009 20:53:44 +0100, Dean Edwards dean.edwa...@gmail.com wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) Or even just one for both: rubric anyone? b -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Wed, Sep 30, 2009 at 3:31 AM, Bruce Lawson bru...@opera.com wrote: On Tue, 29 Sep 2009 20:53:44 +0100, Dean Edwards dean.edwa...@gmail.com wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) Or even just one for both: rubric anyone? rubric and credit (or name) could solve a lot of element rancor on this list (and this icky IE DOM issue). So count me as +1! Erik Vorhes
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
A generic (even if potentially slow) solution to the parsing issues would be tweaking the DOM glue code of http://livedom.validator.nu/ to work in IE (perhaps with SVG Web for SVG subtrees and Math Player for MathML subtrees), adding a way for the tree builder to attach to an existing DOM (go straight to in body and initialize the stack and the head pointer from head, body and html from the tree constructed by the browser's native parser) and conditionally (if an HTML5 parser isn't detected by examining the node produced by document.write(svg/svg);) doing document.write(plaintext) and then handing the contents of the plaintext element to the GWT- compiled JS version of the V.nu parser. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] The new content model for details breaks rendering in MSIE5-7
This will also affect the figure element. Test case: http://dean.edwards.name/test/details.html -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwards dean.edwa...@gmail.com wrote: This will also affect the figure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing in head.) ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com wrote: This will also affect thefigure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing inhead.) I can't get it to work using document.write(). Do you have a live example? And kudos to the guy that discovered this hack. I have no idea how it works but it seems to do the trick. Do you have any background to this hack apart from what was on the W3C list? -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 11:55 AM, Dean Edwards dean.edwa...@gmail.com wrote: I can't get it to work using document.write(). Do you have a live example? Yup. http://www.xanthir.com/etc/html5-details-fix.html (This works in IE8 when the page mode is set to IE7 or Quirks. It's possible that this doesn't actually work in a real IE7 or IE6, but I have no way to test it.) And kudos to the guy that discovered this hack. I have no idea how it works but it seems to do the trick. Do you have any background to this hack apart from what was on the W3C list? Unfortunately, no. We do know that actually wrapping a figure in an object fixes things, but I have no clue how or why putting an unclosed object in the head (which doesn't end up appearing in the actual DOM) works. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 17:55, Dean Edwards wrote: On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com wrote: This will also affect thefigure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing inhead.) I can't get it to work using document.write(). Do you have a live example? It's always the last thing you try. :) http://dean.edwards.name/test/details2.html There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 19:30, Keryx Web wrote: 2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. I'm starting to think that too. MSIE5-7 accounts for about a third of web users. This admittedly clever hack is just too hackish. You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwards dean.edwa...@gmail.com wrote: You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. The third solution, of course, is just to avoid details until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). This whole thing is really much less of an issue than the legend problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. After all, we're already happy enough using divs or dls or whatever to implement that functionality. It would be nice to immediately start using the new stuff, but the timeline for when it's viable isn't so long as to be unworkable. In the meantime, we just keep doing what we're already doing. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 20:41, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwardsdean.edwa...@gmail.com wrote: You have two choices to get around thedd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. The third solution, of course, is just to avoiddetails until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. This whole thing is really much less of an issue than thelegend problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. The legend issue was much easier to fix with JavaScript. But that was a horrible solution as well. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-09-29 21:53, Dean Edwards skrev: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. - figure IS new - details IS new BUT over a few peoples dead bodies it seem, that we should add one or two new elements to make them work that would be: - intuitive and easy to teach - semantically clear and that would have: - zero technical problems - no added costs for browser makers to implement, since it would be done in conjunction with figure and details as such anyway Instead we have a solution that: - currently requires weird and fragile hacks - redefines the semantics of existing elements Just because adding elements is evil. I actually do not know what argument that could sway peoples minds on this issue. It is beyond reason to me. I mean, it is not as if the dt/dd had been carefully discussed and researched BEFORE it entered the spec... Something I thought was a criterion for inclusion. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
