Bug 3245

Summary: Support the 'bdo' element
Product: WebKit Reporter: Dave Hyatt <hyatt>
Component: DOMAssignee: Dave Hyatt <hyatt>
Status: VERIFIED FIXED    
Severity: Normal CC: mitz
Priority: P2    
Version: 412   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 4898    
Attachments:
Description Flags
Handle DIR for all elements in html4.css instead of in HTMLElementImpl
hyatt: review-
Handle BDO in HTMLElementImpl and only there
hyatt: review-
Cache bdo's dir attribute separately from other elements'
hyatt: review+
updated test and expected result
none
updated expected pixel test result none

Description Dave Hyatt 2005-06-01 16:14:48 PDT
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.
Comment 1 Dave Hyatt 2005-06-01 16:15:04 PDT
Apple Bug: rdar://3481337/
Comment 2 mitz 2005-09-10 15:32:46 PDT
Created attachment 3854 [details]
Handle DIR for all elements in html4.css instead of in HTMLElementImpl 

mjs and darin suggested this solution
Comment 3 Dave Hyatt 2005-09-10 16:14:19 PDT
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.
Comment 4 Dave Hyatt 2005-09-10 16:21:55 PDT
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). 
Comment 5 mitz 2005-09-10 16:36:06 PDT
Created attachment 3855 [details]
Handle BDO in HTMLElementImpl and only there

Taking the other approach
Comment 6 Dave Hyatt 2005-09-10 16:37:12 PDT
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 7 Dave Hyatt 2005-09-10 16:41:01 PDT
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).
Comment 8 mitz 2005-10-03 02:34:19 PDT
Created attachment 4176 [details]
Cache bdo's dir attribute separately from other elements'
Comment 9 Dave Hyatt 2005-10-03 11:21:25 PDT
Comment on attachment 4176 [details]
Cache bdo's dir attribute separately from other elements'

r=me
Comment 10 mitz 2005-10-03 11:31:46 PDT
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.
Comment 11 mitz 2005-10-03 11:32:57 PDT
Created attachment 4181 [details]
updated expected pixel test result

This is the expected result with the patch for bug 4898 in place.
Comment 12 mitz 2005-10-09 10:14:09 PDT
Oops, forgot that it wasn't my bug. I shouldn't have been the one to mark this 'verified'.