Remove filter: mask(), which breaks CSS validation

tracking

Seems like something similar to here is fixed:
http://20.targetprocess.com/2006/07/ie6-select-and-z-index-problem.html

From a first quick look this could be fixed as a quick fix by only serving the css file on node/*/edit and node/add/* via template.php preprocess_page
Actually why not print the "mask style" inline? I believe the element ui-datepicker-cover comes from ui.datepicker.js

Minor yes, but breaks CSS validation on every site which uses date picker...which is anoying for many people (including myself).

I'd like a fix for this, so that my clients can see nice CSS validation, with out having to hack date myself.

Thanks you guys in advance,
Jordan of http://cubiclecollective.com

Maybe it should be added via jQuery, similar example with Mootools : http://www.designlessbetter.com/blogless/posts/validating-opacity-in-css-21

I agree, very annoying.

Some of my competition use the valid html and css links at the bottom as a marketing tool to convince clients they are better. My whole site validates except for this one little error for stupid IE (again IE).

It should be a separate style sheet for IE only which only gets added if IE is calling it. Most themes do that nowdays anyway, so it would jut be a matter of inserting it into the page.tpl for people who want it to work in IE. For me the Date_picker is only for admin, so I make sure my clients use anything but IE anyway.

Good module though.

This is required by the jQuery module, I'm just using what they say is required. I don't have the time or ability to hack their requirement and test that the hack won't break something. You can not use this module or create your own override in your theme.

If someone comes up with a patch to do something different and others are willing to test that it doesn't break anything, I will add it in. But I'm not going to try to do it otherwise.

Read #6.

This patch works beautifully, Dane you're an absolute genius

There are a few other modules which have this same issue:
Nice Menus - http://drupal.org/node/256099
Thickbox - http://drupal.org/node/238563

I think your approach is cleanest I've seen so far

I confirm Dane's patch in #12 is OK, the offending CSS is striped except for MSIE < 7, Date picker UI works under MSIE 6 but I have no way to know whether the CSS is added since it does not show in the source (normal, jQuery insert).

BUT strangely, the patch does not apply, it gives the error "can't find file to patch at input line X". I tried with Dave's patch #12 and tried to roll a new patch against CVS DRUPAL-6--2 with no luck. So the changes seem to have to be made manually.

KarenS, where in jQuery module do they require the use of mask() ?

@Dane for the patch :

guix@james-bond:~/tmp$ wget http://ftp.drupal.org/files/projects/date-6.x-2.x-dev.tar.gz
guix@james-bond:~/tmp$ tar xvzf date-6.x-2.x-dev.tar.gz
guix@james-bond:~/tmp$ cd date
guix@james-bond:~/tmp/date$ wget http://drupal.org/files/issues/date-352975-12.patch
guix@james-bond:~/tmp/date$ patch < date-352975-12.patch
(Stripping trailing CRs from patch.)
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: date_popup/lib/ui.datepicker.js
|===================================================================
|--- date_popup/lib/ui.datepicker.js	(revision 654)
|+++ date_popup/lib/ui.datepicker.js	(working copy)
--------------------------
File to patch: date_popup/lib/ui.datepicker.js
patching file date_popup/lib/ui.datepicker.js
(Stripping trailing CRs from patch.)
can't find file to patch at input line 18
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: date_popup/themes/datepicker.css
|===================================================================
|--- date_popup/themes/datepicker.css	(revision 656)
|+++ date_popup/themes/datepicker.css	(working copy)
--------------------------
File to patch: date_popup/themes/datepicker.css
patching file date_popup/themes/datepicker.css
Hunk #1 FAILED at 134.
1 out of 1 hunk FAILED -- saving rejects to file date_popup/themes/datepicker.css.rej

Same with my own rolled patch against CVS. File to patch: date_popup/lib/ui.datepicker.js and File to patch: date_popup/themes/datepicker.css were entered manually.

For datepicker, from date_popup/lib/README.txt :

If jQuery UI is installed, the version of the 'datepicker' code from
that module will be used.

If jQuery UI is not installed, the 'datepicker' code from this folder
will be used.

See:

- http://docs.jquery.com/UI/Datepicker/datepicker
- http://ui.jquery.com/functional_demos/#ui.datepicker
- http://plugins.jquery.com/project/timeEntry

So the code comes either from :
- jQueryUI, which has to be downloaded from jqueryui.com and wrapped with the jQueryUI Drupal module
- ui.datepicker.js from this module

So including ui.datepicker.js must be a tactical choice of the maintainers to avoid having to install the jQueryUI Drupal module and the external lib.

I'm thinking loud here, sorry if writing worthless lines !

After screwing around with this for a long time and investigating other alternatives, I decided the best fix was to remove that css and provide information in the Date Popup configuration screen on what to add back if you have trouble.

1) The css fix is IE6-specific. No other browser is affected by it, but it does break validation.
2) There is no easy way for a module like Date Popup to add it back conditionally in a way that it won't exist for other browsers, but there are many ways for you to do that in your theme (look at the way the Garland theme handles it in page.tpl.php). Drupal's methods of handling these things all assume you are doing it in the theme.

Since it is easy to fix in the theme and hard for a module to fix, and we're already up to IE8, I think I prefer to remove it and let those who need it add it back in the theme. I added information about this at admin/settings/date_popup, including the css that you may want to add back.

For the other questions above:

1) The preferred method of getting the datepicker js is to install jQuery UI (which will almost always be more up to date than this module will). There is a version of the datepicker included here for convenience, but I will eventually add a dependency on jQuery UI and remove it. It can be included because it is GPL, just as the rest of the jQuery code in core is.

2) Because we ultimately don't have control over the source datepicker code, altering it is not really an option. The datepicker.css file adapted here is the only part of the code we really control, so I am fixing that. There may still be things in the source code you don't want, and you need to file issues with jQuery UI for those.

Nice, KarenS ! Totally a good decision to add a dependency on jQuery UI. This is solid stuff.

@guix, you should post your proposal in #3 to the jQuery UI module. That would be the best place to fix this and that fix looks like something jQuery UI could implement.

This is the right decision.

Time to end the ie6 nightmares :)