11/12/03 2:15 AM Dave Hyatt: The <bdo> element is not supported. This element is acts as "unicode-bidi: override" in CSS and needs to support the dir attribute mapping into the direction CSS property. I believe it is a block but I'll have to double-check.
Apple Bug: rdar://3481337/
Created attachment 3854 [details] Handle DIR for all elements in html4.css instead of in HTMLElementImpl mjs and darin suggested this solution
I disagree with mjs' and darin's recommendation. This patch will regress performance significantly by defeating the style sharing optimization for siblings and cousins completely, effectively turning it off for all of HTML. A rule with a universal selector is one that has to be checked by every single element, thus creating additional work that will occur on every single style match of an HTML element. In general, for the universally applied HTML attributes, that is why I left the checking in code rather than in the CSS file. Furthermore, once an element is affected by attribute selectors, it no longer tries to share with siblings. This is technically a limitation in the sharing heuristic that should be improved (attributes that are not mapped in code but used in style cause sharing to be turned off). One idea would be to treat all attribute selectors used in the user agent sheet as mapped, although there are subtleties that would have to be addressed (right now we actually *depend* on form controls not sharing for example, and would then have to add some more checks for all the control states like disabled and checked to the sharing heuristic). Even if we fix the sharing code to deal with attribute selectors better, getting an attribute is not currently O(1), it is O(m), where m is the # of attributes present on the element. Therefore this solution is slower than the parseMappedAttribute solution would be, since that involves work that only occurs when a dir attribute is encountered, and only involves a single hash lookup to locate the appropriate mapped style declaration.
Basically in general right now in terms of both speed and footprint, parseMappedAttribute is superior to attribute selector rules in html4.css. Moving current rules into parseMappedAttribute would in fact improve both footprint and performance (e.g., table[align="center"] defeats all style sharing on table elements for example, forces all tables to actually do a getAttribute of their align attributes (taking a worst-case hit when it is not present).
Created attachment 3855 [details] Handle BDO in HTMLElementImpl and only there Taking the other approach
Note that I do ultimately favor a declarative solution toe the mapped attribute problem, possibly using a vaguely-CSS-like syntax, but this would not involve the creation of normal style rules. It would still ultimately be mapped attributes that are resolved at attribute-changed time and not during style matching.
Comment on attachment 3855 [details] Handle BDO in HTMLElementImpl and only there The mapped attribute table is a cache from an attribute name and value pair to a style declaration that holds the desired CSS properties and values that you want the attribute/value pair to map to. In this case, dir on the <bdo> tag has a different meaning than on all other HTML elements. This means that the mapped attribute cache needs two distinct entries for dir, one for <bdo> and one for all other HTML elements. This is the reason that the mapToEntry function returns the set of enumerated constants like eUniversal. You need to make <bdo> use a new enumerated constant (e.g., eBDO) for the dir attribute so that it is cached separately from dir attributes on other elements. Otherwise the mapped attribute cache might incorrectly hand back the wrong mapped attribute style declaration for your element (e.g., treating an HTML element like <bdo> or <bdo> like another HTML element).
Created attachment 4176 [details] Cache bdo's dir attribute separately from other elements'
Comment on attachment 4176 [details] Cache bdo's dir attribute separately from other elements' r=me
Created attachment 4180 [details] updated test and expected result This is the expected result with the patch for bug 4898 in place. Also removed the line that says that the test is expected to fail.
Created attachment 4181 [details] updated expected pixel test result This is the expected result with the patch for bug 4898 in place.
Oops, forgot that it wasn't my bug. I shouldn't have been the one to mark this 'verified'.