homepage Welcome to WebmasterWorld Guest from 54.167.10.244
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

This 40 message thread spans 2 pages: 40 ( [1] 2 > >     
the all too obvious underscore @media hack
@media, underscore hack, IE version targetting
Komputist




msg:3601251
 4:41 am on Mar 15, 2008 (gmt 0)

Common knowledge 1:

selector{                                         
  property:ying;                  
#property:yong; /*IE7*/         
_property:yang; /*IE4,IE5,IE6*/  
}

Common knowledge 2:

There are many @media hacks. They are nice for targetting spesific browser versions.
However, they also have complicated syntax and gotchas ... Hard to learn and master.

2+ 2 =

#@media all {  /*IE7*/                                
selector { property: yong;}
}
_@media all {  /*IE4,IE5,IE6*/                        
selector { property:yang; }
}

(I have not seen this, rather obvious, solution mentioned on the many sites that discusses @media hacks. Please educate me if I have overlooked something.)

[edited by: Komputist at 5:05 am (utc) on Mar. 15, 2008]

 

DrDoc




msg:3601285
 5:43 am on Mar 15, 2008 (gmt 0)

The reason why someone would use broken, invalid, and prone-to-blow-up-some-day CSS to target IE in favor of the completely safe and 100% intentional Conditional Comments is beyond me ...

Komputist




msg:3601420
 12:47 pm on Mar 15, 2008 (gmt 0)

I guess it is now I should ask why anyone would compare a CSS hack with a HTML based hack … Anyway, here are

The underscore @media advantages over Microsoft® Conditional Comments™

  1. Conditional Comments™ must appaer inside HTML, and are used to serve Internet Explorer a separate style sheet. Separate style sheets are, in themselve, a complication. The underscore @media hack allows to keep just one style sheet.

  2. It can't blow up. MS IE 4 to 7 are not going to be "fixed" so that the underscore hack doesn't work anymore. If it doesn't work in IE8 (anyone to confirm?), then it makes the undescore hack the more useful. (I assume IE8 "support" depends on whether it is in IE7 mode or not? And if so, it should be safe to use.)

  3. Microsoft® Conditional Comments™ are in themselves hard to remember. (My text editor wastes an entire sub menu on them ... )

  4. Finally, it has to be said the normal underscore hack is a CSS property based hack. Wherease that @media is an advanced selector, and thus _@media all{} and #@media all {} are therefore selector hacks. And they are by no means the only selector based hacks. And selector based hacks are also used to target not just IE, but also other user agents, including Firefox. (A User Agent is supposed to drop a the entire style rule, if the selector is invalid or if the UA doesn't understand it.)

[edited by: Komputist at 12:49 pm (utc) on Mar. 15, 2008]

SuzyUK




msg:3601472
 2:57 pm on Mar 15, 2008 (gmt 0)

Welcome to WebmasterWorld! Komputist

You know what they say.. if it looks to good to be true...

The way I see it is that complex, ugly, messy filters are no longer a necessity and educating people to use them is wrong when there is a standard, or at least accepted way now. Maybe this is the reason why they're not discussed, the balance has tipped!

Please educate me if I have overlooked something.

You probably haven't overlooked anything at least in the technical sense, but Hack Management is probably more important than technicalities as far as CSS's future uptakers is concerned.

This filter assumes firstly that everyone using it knows that _ no longer works for 7+ and that # which still works for 7 is a safe filter. It might be it might not I cannot confirm either way.. either way the hack management ethos is that you only hack backwards, progressive enhancements may be delayed if parse filters remain in place (as happened with the IE7 launch?)

I guess it is now I should ask why anyone would compare a CSS hack with a HTML based hack

Hack Management should now be our responsibility to ensure standards continue to be built and met. We're at the point now where we're not just pioneering how CSS should work anymore (why CSS filters were useful in the past) but instead we're at the point were the words "Standards Compliant" are accepted as important.. So we now need to take the complications out of the CSS to show that it works the way it's supposed to, it's compliant with the recommendations it always has been. It's not CSS that's broken so why poison it with the patches? It's IE that was broke so let IE fix itself behind its own proprietary, HTML filtered, version targeted door.

That single stylesheet is always ever likely to a dream, with IE introducing another version targeting switch (clever how they got that one accepted ;))

The HTML version filter (Conditional Comment) gives nice little labelled boxes for everybody to use then throw away when no longer required.
IE5.. oh you're not not supporting that anymore so you can safely delete the IE5 conditional.. how do propose explain how/when someone can safely do that with the parse filters in the future?

While parse hacks and filters have been useful in the past I'm certainly not happy allowing any more to filter into greater usage, templates etc.. I just don't think it's responsible to introduce more confusion than is necessary into CSS code.

The HTML filter is deliberate, is much clearer going forward, it actually has "IE" and often the version number in it and even the less advanced coders, or newcomers to web dev can see what it's doing, or a least that it's doing something different for IE (not CSS)

Do your bit for the Environment - Keep CSS Clean!
let CSS move forward, keep it clean.. let it shake of the hackles of "the it's no good because it breaks IE", let's put the responsibility back on that bad old IE and put IE, not CSS, in an HTML Filtered cupboard and let's not let it back out until IE's got it right!

the @media filter looks like it would work but why re-introduce mess into CSS, it doesn't need it.

[edited by: SuzyUK at 3:13 pm (utc) on Mar. 15, 2008]

Komputist




msg:3601535
 5:17 pm on Mar 15, 2008 (gmt 0)

Thanks for the welcome, SuzyUK! When I decided to publish my little discovery here, it was amongst otherthings because I found your postings of - what I would describe as - hacks related to hasLayout. :) (I also very much like the style of the forum and such things as well!)

You probably haven't overlooked anything at least in the technical sense, but Hack Management is probably more important than technicalities as far as CSS's future uptakers is concerned.

Using the @media is a form of Hack Management. Just as Conditional Comments is. But @media is simpler, IMHO, than Conditional Comments. Simpler, because you can manage the CSS hacking where it should be kept - inside the style sheet, instead of in the HTML.

It might be […] I cannot confirm either way..

Not sure I understand. The underscore hacks should be well documented.

either way the hack management ethos is that you only hack backwards, progressive enhancements may be delayed if parse filters remain in place (as happened with the IE7 launch?)

Hm. First about the ethos part: Using the underscore - or any of the other characters that Anne mentions in his post - should, today, genarllyh speaking be backward compatible hacking. Microsoft will not be adding new kinds of "underscore characters", they will only be removing them. So why no use them during the "countdown"? (Anyone who has tested IE8, please verify what then ...)

And as for progressive enhancements: Microsoft "fixed" the underscore and the hyphen-minus in IE7. The rest - except perhaps * in standards mode (may be there are other exceptions?) - of the characters that IE ignores, Microsoft conveniently "forgot". Thus the massive use of the underscore character lead MS to remove the underscore "support" from IE7. Brilliant, if you ask me, since this lead to a filter being created. Such as also noted about the star hack.

I really am not convinced that using this hack prevents any developement at all. I doubt it. And, by the way, one of your own hacks dealing with hasLayout goes like this

/* IE needs the values given in 2 x parts for some strange reason */
* html .box {display: inline-block;}
* html .box {display: inline;}


In my book, this is a underscore hack. Not literally, since you use the star character instead of the underscore letter. But both star and underscore belongs to the list of characters which IE overlooks. (Again, see Anne's blog post.)

The code you use, * selector is tecnically valid from a purely CSS standpoint. But it is completely unlogical from a HTML point of view. But by using this hack, you in fact helped getting Microsoft to remove support for this hack (in IE7, when it is in standards mode). (However, according to CSS discuss, you can now use *+html .box{} [css-discuss.incutio.com] instead … Logical, since the + character are amongst the character that Anne mentinoed.)

Anyway, your hack could be simplified - in my book, by applying the @media hack instead. Because, in your hack, each line is "double hacked": each line has a selector hack. And in addition to that, each style rule applies your intricate knowledge about what inline-block and inline does to hasLayout.

You could instead have isolated the selector part of your hack - in order to help "newcomers to web dev" – like this:

* @media all{
.box {display:inline-block;}
.box {display:inline; }
}

Keeping CSS for MSIE in a separate CSS file is not simpler for newcomers. Keeping it in a separate section of the same stylesheet might be.

I completely disagree with the IE8 version targetting. But given that Conditional Comments is in fact a proprietary version targeting, I feel I have ammunition against using it. (And I have noted for myself that – for a great part – the good guys that have said "well done" to Microsoft for their new version targetting are the same that first started to prefer Conditional Comments™ in order to be "hack free".)

There are many that brag about how hack free they are. But they are in fact only using a subset of CSS and HTML, a "meta language" that works everywhere, because it works in IE.

It takes - for newcomers - long time to reach understanding about what that meta language looks like. Separating the IE code from the normal code is a good thing. But keeping it separated within the same CSS document, is simpler - for newcomers, and myself as well. Therefore, for newcomers, I think that the approach I have outlined here - the use of _@media all{} - is simpler. :)

[edited by: SuzyUK at 5:25 pm (utc) on Mar. 15, 2008]

[edited by: Komputist at 5:42 pm (utc) on Mar. 15, 2008]

DrDoc




msg:3601542
 5:34 pm on Mar 15, 2008 (gmt 0)

It must be said that filters are hardly needed anymore anyway. It is an extremely rare occasion that I need to "fix" something in IE nowadays (and that includes IE6).

Knowing CSS, and knowing how to avoid problems instead of fixing them makes all the difference in the world.

On several large sites that I manage, I can think of only one or two places where a single separate property had to be fed to IE6 and lower.

Filters and hacks are truly passé ... a piece of nostalgia.


<added>
Gee, are we still talking about hasLayout? Man, that was a long time ago ... and at a time when hacks were still needed. That time has passed.

Please, don't dig up any of my old threads where I tell people how to hack for NN4! :P
</added>

[edited by: DrDoc at 5:38 pm (utc) on Mar. 15, 2008]

DrDoc




msg:3601544
 5:41 pm on Mar 15, 2008 (gmt 0)

the use of _@media all{} - is simpler

The issue I have with that ... and the main reason why I'm against anything remotely looking like a "hack" (i.e. where you introduce broken CSS to supposedly fix something) is that you have no idea how that might affect future browsers, or UAs that you haven't had a chance to test.

They may be well documented ... but hacks are never safe. Never.

Conditional Comments are HTML comments. Ignored by everyone. Guaranteed. Except IE :)

Komputist




msg:3601547
 5:47 pm on Mar 15, 2008 (gmt 0)

Conditional Comments look, from far distance, as hacks.

And they are hacks.

You mistake "valid" for "hack free".

If you are using conditional comments, then you are not hack free.

SuzyUK




msg:3601563
 6:43 pm on Mar 15, 2008 (gmt 0)

Hi Komputist, you're Welcome, glad you like us enough to stay here

now what is about lately that I knew would come back to "bite" ;)

I found your postings of - what I would describe as - hacks related to hasLayout.

They're not hacks, they're hasLayout triggers, needed for IE not CSS, nowhere do I tell anyone how they should filter the trigger to IE ;)

due to discovery of hasLayout and wider acceptance of conditional comments (once IE promoted their use on the release of IE7) and the realisation that parse hack/filters were not safe going forward a few things have changed in the dynamics of discussion in the CSS community :)

I remember when I first posted that discovery, which was originally nothing to do with hasLayout, only that IE would honor inline-block on a block level element using this, IE7 was never supposed to happen so people were settling into the ways of using the [* html] filter, and that to even mention Conditonal Comments then was akin to mentioning the latest "version targetting switch".. hindsight is wonderful however I also remember that I used to try to post a disclaimer that [* html] is only for demo.. please use your preferred filter (got fed up and most people here would know that I do not promote any hacks lightly!)

then IE7 came out and we realised the dream of a single stylesheet was highly unlikely and that it did seem more obvious to feed conditional CSS via a Conditional comment, Ie asked us to, it made sense if we wanted IE's CSS to go the right way.. it also got safe to mention them on forums without getting your head bitten off

so now I find it slightly amusing that people might pick me up not that I found something but that I 'delivered it' wrongly hehe.. because if I'd said what I wanted at that time the version targetting would've gained more criticism than the IE behaviour (hasLayout) we, the CSS community were trying to get to grips with!

there is still a need to deliver hasLayout workarounds for IE, but I am no longer willing to pollute my clean CSS with broken CSS in order to do so, there's no need any more, and I do my little bit to promote the use of comments [webmasterworld.com] for "pointing out" hasLayout triggers that can be used in "single page" sheets. Comments are valid css why would I want them in a selector filter?

It might be […] I cannot confirm either way..

Not sure I understand. The underscore hacks should be well documented.

they are but, and sorry if my original wording was not clear, it's the "#" one I meant I couldn't/wouldn't confirm yes it's still valid for IE7, but it isn't well documented because it's not necessary and whether it's still useful in 8 well that's kind of the point. The fact that you yourself are asking for confirmation as to if it still works in IE8 is testament.. your discovery is a filter that you don't know will still be safe - CC's are safe and allows us to get with CSS without trying to outhink IE

sorry if I missed some of your points there's loads to read and I'll re-read again later, thanks for the interesting topic!

-Suzy

SuzyUK




msg:3601564
 6:45 pm on Mar 15, 2008 (gmt 0)

sorry started that about 2 hours ago and x-posted

Conditional Comments look, from far distance, as hacks.

I disagree, to me your filter is the CSS Hack, CC's are a safe IE filter

our beloved CSS does not need hacks anymore, it's time to 'filter' or lay the blame where it lies!

<added> - this has nothing to do with validation or being 'hack' free, we will not be IE free for a long time so separate it from valid CSS please

[edited by: SuzyUK at 7:10 pm (utc) on Mar. 15, 2008]

Komputist




msg:3601576
 7:10 pm on Mar 15, 2008 (gmt 0)

They're not hacks, they're hasLayout triggers, needed for IE not CSS, nowhere do I tell anyone how they should filter the trigger to IE ;)

I am sorry, but using the star character the way you did is nothing but a filter.

SuzyUK




msg:3601581
 7:29 pm on Mar 15, 2008 (gmt 0)

I am sorry, but using the star character the way you did is nothing but a filter.

I know! but nowhere did I recommend the *filter* itself (and that post with the filter is 2.5 years old.. it's been mentioned lots since with the 'use your preferred filter" disclaimer in place)

read the post above that one please.. at the time you lift the quote

IE7 was never supposed to happen so people were settling into the ways of using the [* html] filter, and that to even mention Conditional Comments then was akin to mentioning the latest "version targetting switch".. hindsight is wonderful

pheww - I hope you don't have to explain your filter's reasoning so much when IE8/9 comes out ;)

this time you came and asked about a filter, that's the difference between my "hack" and your filter

my IE hasLayout trigger can be delivered by any filter you like.. but you asked about your "obvious" filter.. so this is a different discussion and your filter is a backwards step - it putts the onus back on CSS,

CSS persons (or a lot of them) are well aware that there are CSS filters that can be used to compensate for IE's shortcomings, but why do you think they don't talk about it any more?

It's really not necessary for us to abuse CSS to fix IE any more

Komputist




msg:3601604
 8:35 pm on Mar 15, 2008 (gmt 0)

I do not deny that my filter is a hack. Far there from. It is code design based on browser quirks, in order to solve other quirks. But that does not take away the fact that CC's are a workarounds [as] well. They are Microsoft designed hacks.

Btw, your very brilliant Tripswitch hack, why do you, in the posting you pointed to [webmasterworld.com] call it a filter, now, when you have taken out the star character from it?

Since you use CC-s (and I don't claim to not use them), and thus MS spesific hack-sheets, do you then also keep those hack-sheets internally valid? Or does it not matter? If you don't bother, then dare I propose that you use this _@media filter to - for instanse - serve spesific values to IE6 versus IE7, inside that hack-sheet? Or do you prefer applying filter characters (underscore etc) and comments to each and every style property/rule?

I feel that you and DrDoc exaggerate a bit how unsafe it should be to use the underscore based hacks ... Especially DrDoc got me to think that perhaps the safest thing is to not code at all, because you never know how it will be interpreted some day. Even the CC hack rely on on other browser to not start to read inside HTML comments. But who konws if that will hold? Of course it is permitted to use one's head and conclude that that is unlikely. But it is also permitted to use the same head about underscore based hacks as well.

CSS has error handeling built into the language. We are allowed to use that.

[edited by: Komputist at 9:15 pm (utc) on Mar. 15, 2008]

Komputist




msg:3601610
 9:12 pm on Mar 15, 2008 (gmt 0)

I understand (better) now that your opinion has changed, and that you now prefer CCs.

and your filter is a backwards step - it putts the onus back on CSS,

CSS persons (or a lot of them) are well aware that there are CSS filters that can be used to compensate for IE's shortcomings, but why do you think they don't talk about it any more?

It's really not necessary for us to abuse CSS to fix IE any more


You mean one should always - I understand with certain exceptions such as for the Tripswitch hack - take the trouble and serve extra stylesheets, either via CCs (hah, CSS versus CCs ...). Perhaps you accept serving the hack-sheet via other hacks as well [gunlaug.no]? (Or would that CSS hack there put "the onus back on CSS" again?)

That - or this - might be the ideal thing.

But whatever CSS persons talk about: These hacks exist, and people will use them. I bet you use them yoursleves, often, just to test the effect of doing this or doing that. And for those that use such hacks - now or then or always, it is useful to know about the underscore @media hack - because it can help them hack less and to manage the hacks better. Definitely simpler, and defintely an improvement. (For instance, it make it simpler to move the hacks over to an external stylesheet.)

There is no need to hide knowledge.

(I guess we are nearing the end of this conversation, but I'll still be listen in. )

SuzyUK




msg:3601627
 9:57 pm on Mar 15, 2008 (gmt 0)

I understand (better) now that your opinion has changed, and that you now prefer CCs.

fwiw.. my opinion has never changed it's just that no-one ever asked before ;) ask my *opinion* and you will very likely get a different answer regardless of the textbooks?

Clark




msg:3601644
 10:16 pm on Mar 15, 2008 (gmt 0)

I couldn't read this to the end...confusing..and scary...I think back to the css I copied from standards sites for taming lists, sliding doors etc, that use tricks to get things to work..or when things don't work, fixes to haslayout...and now I wonder if I got stuff in my CSS that don't belong...

Damn this CSS learning curve is a real pain...

Komputist




msg:3601677
 11:09 pm on Mar 15, 2008 (gmt 0)

fwiw.. my opinion has never changed

Ok, so your opinion has not changed. You could accept the Tripswitch hack directly inside the normal stylesheet then …

… and you do the same today. ;)

DrDoc




msg:3601755
 1:28 am on Mar 16, 2008 (gmt 0)

fwiw from my point of view ...
I never use hacks anymore. Ever.

Not in new development at least.

MarkFilipak




msg:3601776
 2:05 am on Mar 16, 2008 (gmt 0)

Whew! What a firestorm.

Komputist: In terms of site maintenance, isn't it easier to someday delete an ie7hacks.css file than it is to edit all your main CSS files? Think about it.

DrDoc




msg:3601807
 3:23 am on Mar 16, 2008 (gmt 0)

Although, for a busy site ... those extra requests to the server really add up!

MarkFilipak




msg:3601828
 4:10 am on Mar 16, 2008 (gmt 0)

> extra requests to the server really add up!
Maybe CSS needs an in-line conditional include to match the CC in HTML, eh?

DrDoc




msg:3601829
 4:17 am on Mar 16, 2008 (gmt 0)

Not really ... The browsers should just support the standard. Period.

SuzyUK




msg:3602030
 11:57 am on Mar 16, 2008 (gmt 0)

[slightly OT] but just to clarify something in case others happen on this discussion later and because I feel responsible


And, by the way, one of your own hacks dealing with hasLayout goes like this
/* IE needs the values given in 2 x parts for some strange reason */
* html .box {display: inline-block;}
* html .box {display: inline;}

correction if you don't mind, that is not the hasLayout 'hack', that quote was taken from a different time altogether from a discussion about inline-blocks and centered floats [reference] [webmasterworld.com] that was purely experimental code that mostly no-one would be interested in March 2005 because even now in 2008 inline-block is still not fully supported (close now that FF3 has it but still)

at that time IE7 was not out, the hype to stop using parse hacks and start using Conditional comments was not started and hasLayout knowledge was virtually non-existant.. the * in the code in that discussion was simply a way of saying "Only IE needs this" - even in that discussion though I probably didn't the need the star at all, and was simply using it + comments as my chosen filter to make the 'workaround' obvious for the purposes of discussion couldn't mention CC's back then ;)

The realisation that these two lines of code also safely tripped hasLayout without the need for a parse filter came later when we were discussing what might happen when/if parse hacks disappeared and height got fixed.

To clarify
IE7 still needs some hasLayout fixes - the star will hide it from IE7 - do not use the * filter if using the above code as the haslayout "Tripswitch"

It doesn't need a filter, it can go straight in the main CSS, but I recommend using one, so at the very least comment it or ideally separate it out using Conditional Comments or your preferred filter

.. I'm sorry for soapboxing on your discussion Komputist and get your point about using your filter as separation/simplification for IE which I've more on below, I just don't want anyone to think the star is a part of my "hack", I know how things can get confused easily if not clarified
[/OT]

---------------------------------------------------

Btw, your very brilliant Tripswitch hack, why do you, in the posting you pointed to call it a filter, now, when you have taken out the star character from it?

as just clarified above, I never took the star out, it was never there - it's an IE7 and backwards trigger. My hack/filter was born at a time I hoped it would never be needed (still isn't mostly), so it was not really necessary to explain it back then. I just joked about the fact it might be useful one day, and apparently the day arrived :o - prior to IE7 the Holly Hack wrapped in the star filter coped admirably.

filter, hack. workaround, fix it makes no odds - hack is the better search term.. filter is what it's doing, and it's an IE workaround.
I call it a filter because it's filtering hasLayout to IE and is not 'upsetting' anyone else, technicalities of terminology are not something I waste time on.. it's an IE workaround plain and simple.

You mean one should always - I understand with certain exceptions such as for the Tripswitch hack - take the trouble and serve extra stylesheets, either via CCs..

preferably yes, CC's all the way for all IE workarounds no matter how simple they are.. and I wouldn't make an exception for the "Tripswitch" either. It's the subtle hacks that will cause future confusion (and why I feel responsible for making sure, now that it is out there in the wild, that it at the very least gets commented, hence that post) - I would never have promoted/published the TripSwitch as a inline hack myself - mainly because I still don't know whether IE8 deals with it as expected yet - but it leaked out as these things do so the least I can do is try to make sure it's notated.

You could instead have isolated the selector part of your hack - in order to help "newcomers to web dev" – like this:

* @media all{
.box {display:inline-block;}
.box {display:inline; }
}

as explained above my hack/filter/workaround/hasLayout trigger does NOT need the star in fact it would be detrimental to use it. However to get back to the discussion about parse filters as a method of version targetting .. I'll use this example to help explain what I (and possibly Doc?) mean about "not safe" going forward, I'm not exaggerating anything and I am trying to share my knowledge by talking from experience.

say for example JB had set up the "AnIE Hack" above 3 years ago (pre IE7) and she'd set it up using the handy * parse filter and IE7 when it rolled out no longer needed the ANiE hack - then yes, today, your @media filter preceeded by the star parse filter would be a nice way to 'simplify' or separate it if she likes to have all her CSS in one sheet, and this at least provides a visual clue to her that AnIE is a hack. So yes she knows what it's doing is happy with her lot and incorporates the @media filter too. So the 'whole' hack now looks like the quote above.
BUT
Say the AnIE hack (the inner two rules) are still needed for IE7 when it rolled out.. IE7 was no longer getting the rules because the 'star' is gone, not read/parsed anymore, rendering the whole hack useless. JB is no longer responsible for that sheet, what does her successor do?
1. scrabble around looking for the latest 'CSS Hack'
2. does she even know the hack still works and that she simply needs the latest IE7 "parse filter"?
3. try to learn why it was needed in the first place?
4. come and shout at you (or us here on CSS Forums ;)) cos 'CSS is broken' again?

Now I know and you know, when JB's successor arrives to chat with us or shout at us, that CSS is not broken, that it's not the AnIE hack that's broken.. nor is it the @media separation filter - we know it's the star, the parse error part of it that's 'broken' (see that's why people still mistakenly think CSS is broken!) - however we also now know that the star was not safe to use to filter a forward moving hack. That's the knowledge.. so how would you choose to share it?

I for one would choose to help or educate JB's successor by pointing out that CSS is not broken, IE is (or was), and I would use my knowledge to provide the safest method available to help avoid this happening again. I would not provide the latest parse filter, even though I know one exists. It's not 'hiding knowledge' that is the reason I wouldn't share the filter it's simply using all my knowledge in the best way to try to help and educate. CC's have IE's name on them they are safe and should be used to hold IE workarounds, hacking the CSS using parse errors to do the same is just adding to the "broken" legacy

So back to to your filters and how this all relates.. The star and underscore as back filters may well be safe because we know their fate, although to 100% assume that it will remain safe is also dangerous as that knowledge relies on the fact that any future render engine doesn't go interpreting them wrongly again!

The #, html+ whatever the latest one is, is in limbo.. I don't know if wrapping any hacks (including my own) in it is safe going forward.. I don't know if any hacks will be needed for IE8, I don't know if IE8 will still parse the #, I don't know if IE8 will wrongly start parsing the underscore or any of those other characters again. I don't know if IE8 will have any parse errors to be able to take advantage of if needed.

That's too many I don't knows for me.. so it's not safe going forward!

It's fair enough to use parse filters on personal sites or in testing (and yes I do do both) or on sites that you're always going to be in control of, because you can and you know the history/legacy and because you know if all else fails there will be conditional comments. But introduction of new ones (especially linked with my hack ;)) needs to have these disclaimers with it. To use them in order to have the ideal 'one stylesheet' in theory, is fine, in practice not so.. there's a legacy with them - think of the next generation!

I can't stop people using your clever filters any more than I can get them to put their IE workarounds in a CC I'm just saying I see more potential problems with your method than with CC's and that your way might continue to put the blame for "breakages" back onto CSS

Yes, personally, I could quite happily use one single CC separated sheet which takes full advantage of parse errors for further version targeting, but it might only be responsible for me to do so on my personal site (or else people will pick on me for something I once said, but then I would need a "do as I say not as I do" disclaimer signature though ;))

and yes I agree that hacks will always (or for a long time yet) appear in main sheets, but sadly without people realising they're even there sometimes
e.g. display: inline; on a floated element, inline-block to trigger layout, text-align: center on the body element.. so there is a need to keep up with the educating.

I do like the neatness of your @media wrap/filter, the hope would be that the 4/5/6 part can be dropped later like a conditional,
(btw the 4/5/6 "version target" assumes that everyone already knows how to code the same for IE6 and 5.5, quirky doctypes, tan hacks etc..)

But I strongly disagree with the IE7/8 part it's a moving target - 7 and 8 might need separated and if the # is no longer parsed that might mean that IE7 will continue to be solely targeted - but if the hash is still parsed but IE8 doesn't need the IE7 workarounds what's the new filter for 8 to be?

and I disagree (obviously) with the using of parse filters as a means of IE version targetting from the CSS file.

-Suzy.. phew

[edited by: SuzyUK at 1:49 pm (utc) on Mar. 16, 2008]

Komputist




msg:3602031
 11:58 am on Mar 16, 2008 (gmt 0)

MarkFilipak - sure, a ie7hacks.css is fine. I have also tried that. Though I have sympathy with DrDoc's server request conserns.

DrDoc, regarding your claim to not use any hacks anymore: I then take it that you do not use Conditional Comments either then - right? Because if you don't hack, then there is no need to use them.

SuzyUK




msg:3602043
 12:25 pm on Mar 16, 2008 (gmt 0)

Maybe CSS needs an in-line conditional include to match the CC in HTML, eh?

I think that's been talked about a few times during the "what can IE do make the transition to standards" discussions, but I have to say I'm glad it doesn't appear to be a solution, again it's not CSS that's Broken so it doesn't need a fix.

Komputist




msg:3602063
 1:37 pm on Mar 16, 2008 (gmt 0)

[…]as just clarified above, I never took the star out […]

The realisation that these two lines of code also safely tripped hasLayout without the need for a parse filter came later when we were discussing what might happen when/if parse hacks disappeared and height got fixed.

Despite what you clarified, it does sound as if the understanding of your own hack, has deepend over time. Good to know.

Otherwise, I am glad you were able to say a good thing about my hack.

I am not so much into community thinking as you are. I guess that's a difference between us.

I'll flesh out my hack more later on. Just need to get hold on IE8 first, perhaps. And it might happen in another forum - we'll see.

Komputist




msg:3602065
 1:39 pm on Mar 16, 2008 (gmt 0)


Maybe CSS needs an in-line conditional include to match the CC in HTML, eh?

I think that's been talked about a few times during the "what can IE do make the transition to standards" discussions, but I have to say I'm glad it doesn't appear to be a solution, again it's not CSS that's Broken so it doesn't need a fix.

The false thing in this is that it isn't HTML that is broken either. But the the CC is defnitely a misuse of HTML comments. You might deem it an undangerous HTML hack. But at any rate, HTML is not to blame.

SuzyUK




msg:3602090
 2:28 pm on Mar 16, 2008 (gmt 0)

I have a ever deepening understanding of all hacks whether I use them or not, learning the hacks not only helped me learn CSS properly, it now helps me fix others stylesheets (payroll) ;), personally I do actually have deep respect for all IE hacks as they enable choice and progression to take place

fwiw, I don't 'like' CC's either they're simply the lesser of two evils imho

The false thing in this is that it isn't HTML that is broken either.

agreed but CC's can and are used for more than just CSS, they can be used to filter JS, HTML, anything in the source so they're IEs inbuilt 'get out clause' and were built as an html comment years ago so that's a done deal, I simply recommend using them to pass the buck back to them whatever code it is

Your hack looks really neat and tidy and yes it does seem obvious about the @media wrap now you mention it, please do let us know how it gets on in 8, I'm sure there are others (maybe even me in my personal sheets) who will use it - don't take my opinion as a criticism of your hack!

vincevincevince




msg:3602092
 2:31 pm on Mar 16, 2008 (gmt 0)

Conditional comments fall down because they can't be written within a .css file itself. That makes them fairly useless, at least to me.

The best option is to write for standards and let dodgy browsers render things badly. This is recommended for all but commercial sites.

For commercial sites, I favour user-agent targetting of css files at the server level based upon the USER_AGENT

SuzyUK




msg:3602097
 2:48 pm on Mar 16, 2008 (gmt 0)

Conditional comments fall down because they can't be written within a .css file itself

only if you believe CC's exist solely for the purpose of fixing IE's CSS.. there's more wrong with IE than its CSS rendering, CC's are an IE Version Targeting switch and can filter more than CSS.

To introduce a separate CSS IE version targeting switch just so it can go into stylesheet would be unbearable :o

[edited by: SuzyUK at 2:51 pm (utc) on Mar. 16, 2008]

This 40 message thread spans 2 pages: 40 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved