This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Really this should be two bugs, but I'm lazy. Test-case: data:text/html,<!doctype html> <body style="font-family: Times New Roman, Arial, 'Ahem!', 'serif', serif; transform:rotate(100grad)"> <script> document.documentElement.textContent = document.body.style.fontFamily + "; " + document.body.style.transform </script> Font-family is serialized as: IE10 Developer Preview: Times New Roman, Arial, "Ahem!", "serif", serif Firefox 13.0a1: Times New Roman,Arial,'Ahem!','serif',serif Chrome 18 dev: 'Times New Roman', Arial, 'Ahem!', serif, serif Opera Next 12.00 alpha: "Times New Roman", "Arial", "Ahem!", "serif", serif Spec seems to say like Opera, except it says to string-escape the unquoted "serif" too (which is definitely not right). I suggest instead that the family name be string-escaped if it has to be, i.e., if it contains special characters or matches one of the built-in keywords like serif. Multiword font names that contain no special characters should not be quoted, see <https://bugs.webkit.org/show_bug.cgi?id=79448>. Double quotes should be used for consistency. Transform (mind the prefixes) is serialized as "rotate(100grad)" in every browser except Opera, which serializes it as "rotate(90deg)". The spec seems to support Opera, but I suspect that's just an error, maybe dating back to a time when deg was the only angle unit. Angles should serialize like lengths, as the appropriate <number> followed by the unit in canonical form.
We (Gecko) really need to rewrite our font-family data storage, at which point we'd probably end up with a serialization more like Opera's. I prefer specifying Opera's behavior here.
Why should every family name be quoted? Just for simplicity? I don't have any big objection, but it's somewhat less readable IMO, and not how authors usually input the family names. In the common case, nothing would be quoted, which looks cleaner. I'm more concerned that there might be compat issues of some type, though. <https://bugs.webkit.org/show_bug.cgi?id=79448> removed quotes from WebKit's serialization of font-family because it broke sites. Ryosuke, was that bug specifically because of single quotes? Or would adding double quotes have caused the problem too? More specifically, would WebKit be okay with adding double quotes around all font-family names when serializing, except of course reserved names like serif?
(In reply to comment #2) > I'm more concerned that there might be compat issues of some type, though. > <https://bugs.webkit.org/show_bug.cgi?id=79448> removed quotes from WebKit's > serialization of font-family because it broke sites. Ryosuke, was that bug > specifically because of single quotes? Or would adding double quotes have > caused the problem too? More specifically, would WebKit be okay with adding > double quotes around all font-family names when serializing, except of course > reserved names like serif? We didn't change the CSS serialization algorithm. We're just stripping quotes from font-family when it's used as the value of face content attribute (font element) since the attribute doesn't support quotations within.
Oh, I misunderstood. So the problem in WebKit's case only affected <font face>, and only because of non-browser e-mail clients. Some e-mail clients (evidently including Outlook 2007) don't parse quotation marks in <font face>. Given that, adding quotation marks when serializing font-family would cause problems for editing. Basically, the problem is that some very common editing actions will find the computed font-family (which is serialized per CSSOM rules) and re-output it in <font face>. This will break e-mail clients like Outlook 2007 if the original font-family had quotation marks added by CSSOM, so if CSSOM does this, we'd need workarounds in the editing spec/implementations to work around it. It's also more verbose, and if you use double quotes, it adds entities in the HTML serialization. So I still suggest that font names should be serialized with quotes only if they can't be serialized without quotes. (Yes, it's kind of lame that editing has to account for broken e-mail clients. Web browsers are broken enough. But users object if their richtext webmail doesn't display right for Outlook 2007 users.) I really should have made two bugs. Oops.
(In reply to comment #0) > Spec seems to say like Opera, except it says to string-escape the unquoted > "serif" too (which is definitely not right). No, that's not a <font-family>, that's a <generic-family> which is a keyword and gets serialized as "The keyword converted to ASCII lowercase." per spec. > I suggest instead that the > family name be string-escaped if it has to be, i.e., if it contains special > characters or matches one of the built-in keywords like serif. Multiword > font names that contain no special characters should not be quoted, see > <https://bugs.webkit.org/show_bug.cgi?id=79448>. Double quotes should be > used for consistency. Since this bug is really about <font face>, I don't see much point in changing CSSOM serialization. You need to convert the value before sticking it in <font face> anyway in case it does have quotes. Maybe you argue that you would just HTML-escape the quotes and let it break in Outlook 2007 in such cases, but really, changing the serialization from quotes to unquoted seems like a trivial problem in the editing space. In the case of contenteditable/designMode, you don't even have to use CSSOM's serialization rules, you can define your own. (In reply to comment #1) > We (Gecko) really need to rewrite our font-family data storage, at which > point we'd probably end up with a serialization more like Opera's. I prefer > specifying Opera's behavior here. OK. (In reply to comment #2) > Why should every family name be quoted? Just for simplicity? Yes. Simpler also means less likely to have bugs. > I don't have > any big objection, but it's somewhat less readable IMO, and not how authors > usually input the family names. In the common case, nothing would be > quoted, which looks cleaner. I think looking cleaner isn't very compelling. I've not changed the spec.