Closed Bug 818400 Opened 11 years ago Closed 11 years ago

Unprefix :-moz-scope and pref it off by default on beta and release channel

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20

People

(Reporter: emk, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

Add a preference to control :scope and pref it off.
27.24 KB, patch
dbaron
: review+
Details | Diff | Splinter Review 
Please do not proliferate prefixes anymore.
Hmm.  So the idea would be to not parse :scope, right?
I bore @supports in mind.
Sure.

I'll see what I can cook up, I guess.
Just preffed off for now until we have a setup for auto-preffing-off on beta/release, I guess
Attachment #690052 - Flags: review?(dbaron)
Assignee: nobody → bzbarsky
Whiteboard: [need review]
I guess ifdefs in all.js based on MOZ_UPDATE_CHANNEL would work for the actual builds, but would confuse everybody doing their own build (since that has MOZ_UPDATE_CHANNEL set to default)?
Yeah...  We really need a better solution for this stuff.

Also, I think we should actually use the same pref as <style scoped> for :scope.  I'm just not sure what that is.
My patches for <style scoped> don't actually use a pref at the moment (I misremembered that they did).
Note that I'm also fine with shipping :scope unprefixed and unpreffed.  Not sure how happy everyone else is with that, though.
Depends on: 820148
Comment on attachment 690052 [details] [diff] [review]
Add a preference to control :scope and pref it off.

Why don't you leave it on for nightly/aurora using the mechanism added in bug 820148 (though see bug 814530 -- I'm not completely confident it works yet)?

r=dbaron
Attachment #690052 - Flags: review?(dbaron) → review+
er, meant to say "though see bug 814530 comment 6"
> Why don't you leave it on for nightly/aurora using the mechanism added in bug 820148 

That's the plan once that mechanism works; this patch predates that mechanism existing...
https://hg.mozilla.org/integration/mozilla-inbound/rev/066cdafa5ec3 using the new ifdef magic.
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla20
https://hg.mozilla.org/mozilla-central/rev/066cdafa5ec3
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Is there a bug for preffing this on? What are the conditions for this to happen? RELEASE_BUILD has the side effect of making it opaque if and when we can start using new CSS features in our code base.
> Is there a bug for preffing this on?

Not yet.

> What are the conditions for this to happen? 

Not clear yet.  :(
That said, I think we should enable this and scoped stylesheets together, so the conditions should be the same.
I didn't put the scoped stylesheets support behind a pref.
OK.  Should we just go ahead and unpref :scope then?  Scoped stylesheets are m-c only, right?
(In reply to Boris Zbarsky (:bz) from comment #18)
> OK.  Should we just go ahead and unpref :scope then?

Well... should we be taking into account how far advanced the relevant specification is?  :scope is in Selectors 4, which is a WD at the moment.  I don't remember what "rules" CSS WG members have in terms of unprefixed implementations.

As for the feature itself, I can't really see it changing much that would need us to have it be prefixed, really.

> Scoped stylesheets are m-c only, right?

Yes.

I realise now though that I did not do anything special to make :scope match the style scope element in scoped style sheets.  I guess I should do that...
Depends on: 508725
No longer depends on: 508725
You need to log in before you can comment on or make changes to this bug.