This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have someone implementing <input type='color'> for Gecko and readonly attribute is being ignored in the patch he wrote. However, Webkit and Presto are both implementing <input type='color'> with readonly applying. I am not sure what are the reasons why those implementations are taking into account readonly and I'm not sure why the specification says that we shouldn't allow the element to be readonly. Basically I have no strong opinion for or against. It seems that readonly would be pretty useless given that disabled would apply and we also apply disabled but not readonly for <input type='file'>. Anyway, I believe that Gecko could probably implement <input type='color'> with readonly not applying but I would like to make sure the specification wants to keep that position.
What's the difference between how "readonly" is being implemented, and how "disabled" is being implemented? If this is a control where a distinct "readonly" operating mode makes sense (e.g. it lets you drop down the color picker and view all the color information, but without changing it, much like a radonly text field lets you scroll through the text without changing it), then it makes sense to add it. If it's just a synonym for disabled (which doesn't let you interact with the control at all) then I don't see any value in it.
I could only find Chrome which supported this, and its UI is very confused. Seems like a bug in Chrome. https://code.google.com/p/chromium/issues/detail?id=249515