WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
34529
[CSSOM] issues with cssText and selectorText
https://bugs.webkit.org/show_bug.cgi?id=34529
Summary
[CSSOM] issues with cssText and selectorText
Simon Fraser (smfr)
Reported
Wednesday, February 3, 2010 4:09:17 PM UTC
Resent-From: www-style list <
www-style@w3.org
> From: Daniel Glazman <
daniel.glazman@disruptive-innovations.com
> Subject: [CSSOM] issues with cssText and selectorText Date: February 3, 2010 7:58:15 am PST To: www-style list <
www-style@w3.org
> Message-Id: <
4B699D17.5060009@disruptive-innovations.com
> Hi there, I just discovered that Opera is the only "major" browser that does not return a useless result for selectorText and cssText in some cases that are not edge cases any more... If the selector of a rule contains a ident itself containing a colon, the colon must be escaped in the selector. But its serialization in selectorText and cssText is NOT escaped. The same issue happens with many escaped characters. So the result of cssText and selectorText is useless because unparseable and invalid... FWIW, I have written a small test here
http://glazman.org/forCSSWG/selectorTextBug.html
I said it's not an edge case any more because a small site called Facebook gives its partners embeddable stylesheets with such selectors. I discovered them validating a stylesheet in a famous newspaper's website. It's also super important to have a bijection here for editing environments. If cssText and selectorText are unreliable, then building a conforming style editor is almost impossible. I think we should clarify the situation here, saying that the result of selectorText and cssText must be parseable and represent really what they are the serialization of... FWIW, both Safari and Mozilla fail on the test above. MSIE of course is not even able of running the three lines of script... </Daniel>
Attachments
Fix for Bug 34529 - [CSSOM] issues with cssText and selectorText
(21.90 KB, patch)
2010-05-18 03:58 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Style fix
(21.87 KB, patch)
2010-05-18 04:07 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Add another test
(22.16 KB, patch)
2010-05-18 04:19 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Use Vector<UChar> for better performance
(22.81 KB, patch)
2010-05-18 20:28 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Use Vector<UChar> for better performance
(22.81 KB, patch)
2010-05-18 20:29 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Try to fix Qt compilation error
(24.75 KB, patch)
2010-05-18 21:09 PDT
,
Yuzo Fujishima
no flags
Details
Formatted Diff
Diff
Add test descriptions
(24.97 KB, patch)
2010-05-18 22:53 PDT
,
Yuzo Fujishima
hamaji
: review+
Details
Formatted Diff
Diff
Show Obsolete
(6)
View All
Add attachment
proposed patch, testcase, etc.
Anne van Kesteren
Comment 1
Friday, March 19, 2010 8:11:34 AM UTC
FWIW,
http://dev.w3.org/csswg/cssom/
now defines the rules for how to serialize these things.
Yuzo Fujishima
Comment 2
Tuesday, May 18, 2010 6:35:34 AM UTC
***
Bug 33725
has been marked as a duplicate of this bug. ***
Yuzo Fujishima
Comment 3
Tuesday, May 18, 2010 11:58:46 AM UTC
Created
attachment 56354
[details]
Fix for
Bug 34529
- [CSSOM] issues with cssText and selectorText
Yuzo Fujishima
Comment 4
Tuesday, May 18, 2010 12:07:03 PM UTC
Created
attachment 56357
[details]
Style fix
Yuzo Fujishima
Comment 5
Tuesday, May 18, 2010 12:19:41 PM UTC
Created
attachment 56358
[details]
Add another test
Simon Fraser (smfr)
Comment 6
Tuesday, May 18, 2010 4:19:55 PM UTC
Comment on
attachment 56358
[details]
Add another test In general this looks good, but doing lots of String appends is inefficient. You should use StringBuilder instead.
Darin Adler
Comment 7
Tuesday, May 18, 2010 5:36:05 PM UTC
(In reply to
comment #6
)
> In general this looks good, but doing lots of String appends is inefficient. You should use StringBuilder instead.
Good point! But for building strings a character at a time, StringBuilder isn't efficient either. Vector<UChar> is probably the type of choice, or even Vector<UChar, 256>.
Yuzo Fujishima
Comment 8
Wednesday, May 19, 2010 4:28:04 AM UTC
Created
attachment 56446
[details]
Use Vector<UChar> for better performance
Yuzo Fujishima
Comment 9
Wednesday, May 19, 2010 4:29:46 AM UTC
Created
attachment 56447
[details]
Use Vector<UChar> for better performance
Yuzo Fujishima
Comment 10
Wednesday, May 19, 2010 4:31:12 AM UTC
Simon, Darin, Thank you for reviewing this. I've changed to use Vector<UChar>. Please take another look. (In reply to
comment #7
)
> (In reply to
comment #6
) > > In general this looks good, but doing lots of String appends is inefficient. You should use StringBuilder instead. > > Good point! But for building strings a character at a time, StringBuilder isn't efficient either. Vector<UChar> is probably the type of choice, or even Vector<UChar, 256>.
Early Warning System Bot
Comment 11
Wednesday, May 19, 2010 4:38:09 AM UTC
Attachment 56447
[details]
did not build on qt: Build output:
http://webkit-commit-queue.appspot.com/results/2320319
Yuzo Fujishima
Comment 12
Wednesday, May 19, 2010 5:09:50 AM UTC
Created
attachment 56450
[details]
Try to fix Qt compilation error
Shinichiro Hamaji
Comment 13
Wednesday, May 19, 2010 5:42:45 AM UTC
Comment on
attachment 56450
[details]
Try to fix Qt compilation error WebCore/css/CSSOMUtils.cpp:56 + append(appendTo, String::format("\\%x ", c)); Do we have test case which checks this path? WebCore/css/CSSOMUtils.cpp:76 + if (c <= 0x1f || (0x30 <= c && c <= 0x39 && (isFirst || (isSecond && isFirstCharHyphen)))) Are there any reason we cannot use character literals such as '0' or '9' (or maybe L'0' or L'9') ?
Yuzo Fujishima
Comment 14
Wednesday, May 19, 2010 5:56:09 AM UTC
Thank you for the review. (In reply to
comment #13
)
> (From update of
attachment 56450
[details]
) > WebCore/css/CSSOMUtils.cpp:56 > + append(appendTo, String::format("\\%x ", c)); > Do we have test case which checks this path? >
Yes. Tests 1 through 6 run the path.
> WebCore/css/CSSOMUtils.cpp:76 > + if (c <= 0x1f || (0x30 <= c && c <= 0x39 && (isFirst || (isSecond && isFirstCharHyphen)))) > Are there any reason we cannot use character literals such as '0' or '9' (or maybe L'0' or L'9') ?
I used character code in hopes of making it easier to see if the function truthfully implements
http://dev.w3.org/csswg/cssom/#common-serializing-idioms
Yuzo Fujishima
Comment 15
Wednesday, May 19, 2010 6:53:23 AM UTC
Created
attachment 56457
[details]
Add test descriptions
Shinichiro Hamaji
Comment 16
Thursday, June 3, 2010 5:57:48 AM UTC
Comment on
attachment 56457
[details]
Add test descriptions (In reply to
comment #15
)
> Created an attachment (id=56457) [details] > Add test descriptions
Thanks for your description! This change looks good to me.
Yuzo Fujishima
Comment 17
Wednesday, June 9, 2010 5:44:37 AM UTC
Committed
r60880
: <
http://trac.webkit.org/changeset/60880
>
WebKit Review Bot
Comment 18
Wednesday, June 9, 2010 6:08:27 AM UTC
http://trac.webkit.org/changeset/60880
might have broken Qt Linux Release
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug