Opened 11 years ago

Closed 7 years ago

#14261 closed enhancement (wontfix)

Support other vendor-specific CSS

Reported by: Adam Peller Owned by: Patrick Ruzand
Priority: high Milestone: tbd
Component: DojoX Mobile Version: 1.6.1
Keywords: Cc: [email protected]
Blocked By: Blocking:

Description (last modified by Adam Peller)

This request comes from the Maqetta team. Can you support -moz, -ms and -o in addition to -webkit for things like gradients? Although the mobile platform today is almost exclusively Webkit, apparently there are other platforms in the pipeline which may use the other browsers.

It's unfortunate that this would bloat the CSS. Would it be necessary to build device-specific CSS? Could also use something like or Note: not sure what the license is for PrefixFree.

Change History (8)

comment:1 Changed 11 years ago by Adam Peller

Cc: [email protected] added

comment:2 Changed 11 years ago by Adam Peller

Description: modified (diff)

comment:3 Changed 11 years ago by jonferraiolo

Unfortunately, the browsers are not yet implementing the proposed W3C standard syntax for gradients, probably because they fear the standard might change still, so each browser only recognizes/supports their own prefix. Therefore, duplicate definitions seem to be the only way that things will work at run-time.

Note that Windows Mobile is likely to have reasonable take-up in the marketplace in 2012/2013, especially given the Nokia commitment. So it's not going to be just WebKit?.

Regarding bloat, is there a possibility of build options to strip out all style declarations that don't match a particular target browser, putting the alternate gradients in the *compat* CSS files?

comment:4 Changed 11 years ago by bill

Note that dojox/mobile already has device specific CSS generated from common LESS files. I noticed from the less site that you can specify configuration options to less including a search paths for @imports:

var parser = new(less.Parser)({
    paths: ['.', './lib'], // Specify search paths for @import directives
    filename: 'style.less' // Specify a filename, for better error messages
}); that (theoretically) different builds could import different mixin definitions, ex. the webkit build would import:

.box-shadow (@x: 0, @y: 0, @blur: 1px, @alpha) {
  @val: @x @y @blur rgba(0, 0, 0, @alpha);

  -webkit-box-shadow: @val;

and a windows build would import:

.box-shadow (@x: 0, @y: 0, @blur: 1px, @alpha) {
  @val: @x @y @blur rgba(0, 0, 0, @alpha);

  -ms-box-shadow:    @val;

(And obviously the other less files would call the .box-shadow() mixin.)

I guess that's basically already being done, although apparently without use of the paths[] configuration option? I'm not sure because I don't see the scripts used to generate CSS from the LESS files.

Last edited 11 years ago by bill (previous) (diff)

comment:5 Changed 11 years ago by bill

Milestone: tbd

comment:6 Changed 9 years ago by ykami

Owner: changed from ykami to Eric Durocher
Status: newassigned

comment:7 Changed 9 years ago by Patrick Ruzand

Owner: changed from Eric Durocher to Patrick Ruzand

comment:8 Changed 7 years ago by Patrick Ruzand

Resolution: wontfix
Status: assignedclosed
Type: defectenhancement

this ticket seems outdated today. Last years, more and more webkit- css properties have seen a standard equivalent supported by moz. For the compat specific stylesheets, there are already moz- css properties. Closing the ticket as wontfix.

Note: See TracTickets for help on using tickets.