21901 2013-05-02 11:46:20 +0000 <input type='color'> is said to not support readonly but implementations do it 2013-06-13 22:31:24 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All RESOLVED WONTFIX P2 normal Unsorted 1 mounir ian ian mike contributor oldest_to_newest 87162 0 mounir 2013-05-02 11:46:20 +0000 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. 88864 1 ian 2013-06-06 21:13:58 +0000 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. 89282 2 ian 2013-06-13 22:31:24 +0000 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