Add support for case-insensitive attribute value selectors

Source/core/css/parser/BisonCSSParser-in.cpp

Index: Source/core/css/parser/BisonCSSParser-in.cpp
diff --git a/Source/core/css/parser/BisonCSSParser-in.cpp b/Source/core/css/parser/BisonCSSParser-in.cpp
index 89d21d4bf34d8b59f4e99ad211f7295b5b6a872e..159c2c86be8b6a9dfeda61f99cf40e7f43d7a0fa 100644
--- a/Source/core/css/parser/BisonCSSParser-in.cpp
+++ b/Source/core/css/parser/BisonCSSParser-in.cpp
@@ -1110,6 +1110,17 @@ PassRefPtrWillBeRawPtr<MediaQuerySet> BisonCSSParser::parseMediaQueryList(const
     return m_mediaList.release();
 }
 
+bool BisonCSSParser::parseAttributeMatchType(CSSSelector::AttributeMatchType& matchType, const String& string)
+{
+    if (!RuntimeEnabledFeatures::cssAttributeCaseSensitivityEnabled() && !isUASheetBehavior(m_context.mode()))
+        return false;
+    if (string == "i") {

[eseidel, 2014/07/30 20:12:41]

Why are we going through a string type here?

[fs, 2014/07/31 09:27:15]

Because of one of the following I suppose:
1) there's no operator==(const String&, char)
2) it's more readable than the open-coded version (string.length() == 1 &&
string[0] == 'i')

If you meant s/string type/WTF::String type/, then the answer is "we don't",
because there is an operator== overload for this case (so this compiles to a
call to WTF::equal(const StringImpl*, const LChar*).)

+        matchType = CSSSelector::CaseInsensitive;
+        return true;
+    }
+    return false;
+}
+
 static inline void filterProperties(bool important, const WillBeHeapVector<CSSProperty, 256>& input, WillBeHeapVector<CSSProperty, 256>& output, size_t& unusedEntries, BitArray<numCSSProperties>& seenProperties)
 {
     // Add properties in reverse order so that highest priority definitions are reached first. Duplicate definitions can then be ignored when found.